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Foreword 



,rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document identifies the 3G system specifications for Rel-5. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the CAMEL Application Part (CAP) supporting the fourth phase of the network feature 
Customized Applications for Mobile network Enhanced Logic. CAP is based on a sub-set of the ETSI Core INAP CS-2 
as specified by ETSI EN 301 140-1 [26]. Descriptions and definitions provided by ETSI EN 301 140-1 [26] are directly 
referenced by this standard in the case no additions or clarifications are needed for the use in the CAP. 
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2.1 Specifications used for IMPORTS for CAP 

The following table lists the modules from which CAP V4 imports. For each module, the table indicates in which 
formal specification this module can be found. 

Table 2-1 : Module IMPORTS specifications 



Module Name 


Specification 


Ref 


CSI-DataTypes {itu-t(O) identified-organization(4) etsi(0) mobileDomain(O) umts- 
network(1) modules(3) cs1-datatypes(2) version1(0)} 


ETS 300 374-1 


[24] 


CS2-datatypes {itu-t(O) identified-organization(4) etsi(0) mobileDomain(O) umts- 
network(1) modules(3) in-cs2-datatypes (0) versionl (0)} 


EN 301 140-1 


[26] 


MAP-CommonDataTypes (itu-t(O) identified-organization(4) etsi(0) 
mobileDomain(O) gsm-Network(l) modules(3) map-CommonDataTypes(18) 
version9(9)} 


3GPP TS 29.002 


[11 


MAP-MS-DataTypes {itu-t(O) identified-organization(4) etsi(0) mobileDomain(O) 
gsm-Network(l) modules(3) map-MS-DataTypes(11) version9(9)} 


3GPP TS 29.002 


[11] 


MAP-CH-DataTypes {itu-t(O) identified-organization(4) etsi(0) mobileDomain(O) 
gsm-Network(l) modules(3) map-CH-DataTypes(13) version9(9)} 


3GPP TS 29.002 


[11] 


MAP-ExtensionDataTypes {itu-t(O) identified-organization(4) etsi(0) 
mobileDomain(O) gsm-Network(l) modules(3) map-ExtensionDataTypes(21) 
version9(9)} 


3GPP TS 29.002 


[11] 


TCAPMessages {itu-t recommendation q 773 modules(2) messages(1) 
version3(3)} 


ITU-T Q.773 


[46] 


Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) 
informationObjects(5) versionl (0)} 


ITU-T X.880 


[58] 


TC-Notation-Extensions {itu-t recommendation q 775 modules(2) notation- 
extension (4) versionl (1)} 


ETS 300 287-1 


[22] 





Abbreviations 



For the purposes of the present document, the following abbreviations apply: 
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AC Application Context 

AE Application Entity 

AEI Application Entity Invocation 

APDU Application Protocol Data Unit 

ASE Application Service Element 

ASN. 1 Abstract Syntax Notation One 

BCSM Basic Call State Model 

CAP CAMEL Application Part 

CCF Call Control Function 

CCITT International Telegraph and Telephone Consultative Committee 

CPH Call Party Handling 

CS1 Capability Set 1 

CS2 Capability Set 2 

CS Call Segment 

Circuit Switched 

CSA Call Segment Association 

CSG Closed Subscriber Group 

CSG ID Closed Subscriber Group Identity 

CSI CAMEL Subscription Information 

CSID Call Segment (followed by an identification Number e.g. CSID1) 

DP Detection Point 

DSS1 Digital Subscriber Signalling System No. One 

EDP Event Detection Point 

EDP-N Event Detection Point - Notification 

EDP-R Event Detection Point - Request 

EDS Enhanced Dialled Services 

FE Functional Entity 

FEAM Functional Entity Access Manager 

ffs for further study 

FSM Finite State Model 

gprsSSF GPRS Service Switching Function 

gsmSCF GSM Service Control Function 

gsmSRF GSM Specialized Resource Function 

gsmSSF GSM Service Switching Function 

GT Global Title 

ID IDentifier 

IN Intelligent Network 

INAP Intelligent Network Application Protocol 

IP Intelligent Peripheral 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

ITU-T International Telecommunication Union - Telecommunication Standardization Sector 

LE Local Exchange 

MACF Multiple Association Control Function 

MO Mobile Originated 

MS Mobile Station 

MSC Mobile services Switching Centre 

MT Mobile Terminated 

MTP Message Transfer Part 

NA North American 

O-BCSM Originating BCSM 

PDU Protocol Data Unit 

PE Physical Entity 

PIA Point In Association 

PIC Point In Call 

PLMN Public Land Mobile Network 

PSTN Public Switched Telecommunication Network 

ROS Remote Operations Service 

ROSE ROS Element 

SACF Single Association Control Function 

SAO Single Association Object 

SCCP Signalling Connection Control Part 
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SCP Service Control Point 

SDL System Description Language 

SL Service Logic 

SLP Service Logic Program 

SLPI Service Logic Program Instance 

SM Short Message 

SM-CP Short Message Control Protocol 

SMS Short Message Service 

SMSC Short Message Service Centre 

smsSSF Short Message Service Service Switching Function 

SMF Service Management Function 

SRME gsmSRF Management Entity 

SRSM gsmSRF Call State Model 

SS7 Signalling System no. 7 

smsSSF SMS Service Switching Function 

SSME gsmSSF Management Entity 

SSN Sub-System Number 

SSP Service Switching Point 

T-BCSM Terminating BCSM 

TC Transaction Capabilities 

TCAP Transaction Capabilities Application Part 

TDP Trigger Detection Point 

TDP-R Trigger Detection Point - Request 



Interface specification for telecommunication 
services 



4.1 



General 



4.1.1 Definition methodology 

The definition of the protocol can be split into three sections: 

the definition of the Single Association Control Function (S ACF)/Multiple Association Control Function 
(MACF) rules for the protocol; 

the definition of the operations transferred between entities; 

the definition of the actions taken at each entity. 

The SACF/MACF rules are defined in prose. The operation definitions are in Abstract Syntax Notation One (ASN. 1). 
For details on ASN.l refer to ITU-T Recommendation X.680 [53] and ITU-T Recommendation X.681 [54]. The actions 
are defined in terms of state transition diagrams. Further guidance on the actions to be performed on receipt of an 
operation can be gained from the description of the relevant information flow in ITU-T Recommendation Q.1224 [50]. 

The CAMEL Application Part (CAP) is a ROS Element (ROSE) user protocol. Refer to ITU-T Recommendation X.880 
[58], ITU-T Recommendation X.881 [59] and ITU-T Recommendation X.882 [60] for Remote Operations. The ROSE 
protocol is contained within the component sublayer of Transaction Capabilities Application Part (TCAP) (see ETS 300 
287-1 [22]) and Digital Subscriber Signalling System No One (DSS1) (see ITU-T Recommendation Q.932 [48]). At 
present, the ROSE Application Protocol Data Units (APDUs) are conveyed in transaction sublayer messages in 
Signalling System no. 7 (SS7) and in the EN 300 403-1 [25] REGISTER, FACILITY and call control messages in 
DSS1. Other supporting protocols may be added at a later date. 

The CAP (as a ROSE user) and the ROSE protocol are specified in ASN.l, as defined in ITU-T Recommendation 
X.680 [53], ITU-T Recommendation X.681 [54], ITU-T Recommendation X.682 [55] and ITU-T Recommendation 
X.683 [56]. The encoding of the resulting Protocol Data Units (PDUs) shall be done in accordance with the Basic 
Encoding Rules as defined in ITU-T Recommendation X.690 [57]. 
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4.1 .2 Example physical scenarios 



The reader is referred to Intelligent Network Capability Set 1 (CS1) Core INAP [24] for details of the example physical 
scenarios. 



SCP 



SSP 





ISUP 




IP 


SSF 


SRF 





Scenario 1 , Direct Path to IP (Ref. CS1 cases b) & d)). 
Figure 4-1/1 : Scenarios 
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Figure 4-1/2: Scenarios 



InitiatingSS 





SCP 



ISUP 



AssistingSSP 
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Scenario 2a, Connection to IP via an assisting gsmSSF with relay function; IP co-located with assisting gsmSSF 
(Ref. CS1 case c)). 

Figure 4-1/3: Scenarios 
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SCP 




Initiating 
SSP 



Figure 4-1/4: Scenarios 




Scenario 2b; Connection to IP via an assisting gsmSSF with relay function; IP not co-located with sssisting gsmSSF 
(Ref CS1 case c)). 

Figure 4-1/5: Scenarios 

SCP 




Figure 4-1/6: Scenarios 
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SCP 



internal 




Scenario 3 , Connection to IP with relay function; IP co-located with gsmSSF (Ref CS1 case a)). 

Figure 4-/7: Scenarios 
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Figure 4-1/8: Scenarios 
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Scenario 4, Connection to IP with relay function; IP not co-located with gsmSSF (Ref CS1 case a)). 

Figure 4-1/9: Scenarios 
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SCP 




Figure 4-1/10: Scenarios 




SGSN 



Scenario 5, GPRS interworking. No connection to IP. 

Figure 4-1/1 1 : Scenarios 

The following table summarises the scenarios and corresponding interface connections that shall be supported by the 
CAP protocol. The following terms used in the table are defined as follows: 

Basic: Fully defined in CAP and may be used between any two network operators supporting CAP. 

Bilateral: Additional clarifications of CAP capabilities between network operators and/or equipment vendors are 
necessary in order for CAP to be used between any two network operators supporting CAP. 

Direct: This refers to the case where CAP Operations are exchanged between the gsmSRF and the gsmSCF 

via a transaction-level relationship established directly between the gsmSRF and the gsmSCF. 

Relay: This refers to the case where CAP Operations are exchanged between the gsmSRF and the gsmSCF 

via two transaction-layer relationships. These relationships are: 

gsmSCF to/from gsmSSF; 

gsmSSF to/from gsmSRF. 

The gsmSSF sends operations it receives from the gsmSCF to the gsmSRF, and operations it receives from the gsmSRF 
to the gsmSCF. This is done without unpacking (and thus processing) of the relayed operations. 

The gsmSSF function referred to in the table is always located in an MSC or GMSC. 

The gprsSSF function referred to in the table is always located in an SGSN. 
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Table 4-1 



Scenario 


Interface Support 


GsmSSF 

to/from 

gsmSCF 


gsmSSF 

to/from 

gsmSRF 


gsmSSF 
to/from 
assisting 
gsmSSF 


gsmSRF 

to/from 

gsmSCF 


assisting 
gsmSSF 
to/from 
gsmSCF 


Scenario 1 

gsmSRF in IP connected to gsmSSF 
in MSC or GMSC via ISUP and 
accessed by gsmSCF through direct 
Signalling System No. 7 Connection 


See Note 1 


See Note 2 




See Notes 3 
and 6. 

For gsmSRF in 
VPLMN see 
Note 4; For 
gsmSRF in 
HPLMN see 
note 5 




Scenario 2a 

assisting gsmSSF in MSC or GMSC 
connected to gsmSSF in MSC or 
GMSC via ISUP. Assisting gsmSSF is 
accessed by gsmSCF through direct 
Signalling System No. 7 Connection. 

gsmSRF is co-located with assisting 
gsmSSF and accessed (by gsmSCF) 
by relay via assisting gsmSSF over an 
internal nodal interface 


See Note 1 
For gsmSRF in 
VPLMN see 
Notes 4 and 6; 
For gsmSRF in 
HPLMN see 
note 5 and 6 




See Note 2 




See Note 3 


Scenario 2b 

assisting gsmSSF in MSC or GMSC 
connected to gsmSSF in MSC or 
GMSC via ISUP. Assisting gsmSSF is 
accessed by gsmSCF through direct 
Signalling System No. 7 Connection 

gsmSRF is in IP connected to 
assisting gsmSSF and accessed (by 
gsmSCF) by relay through ISUP or 
DSS1 via assisting gsmSSF 


See Note 1 

See Notes 4 
and 6 


See Notes 4 
and 6 


See Note 2 




See Note 3 


Scenario 3 

gsmSRF is co-located with a gsmSSF 
in an MSC or GMSC and accessed by 
relay via gsmSSF over an internal 
nodal interface 


For gsmSRF in 
VPLMN see 
Notes 4; For 
gsmSRF in 
HPLMN see 
notes 5 and 6 


- 


- 


- 


- 


Scenario 4 

gsmSRF in IP connected to gsmSSF 
and accessed by gsmSCF by relay 
through ISUP or DSS1 via gsmSSF 


See Notes 4 
and 6 


See Notes 4 
and 6 


- 


- 


- 



NOTE 1: Basic for establishment of interface when CorrelationID and SCFiD are transferred in the 

AssistingSSPIPRoutingAddress. Bilateral when CorrelationID and SCFiD are transferred by other means 
than in the AssistingSSPIPRoutingAddress. 

NOTE 2: Basic for establishment of interface when CorrelationID and SCFiD are transferred in the Called Party 

Number. Bilateral when CorrelationID and SCFiD are transferred by other means than in the Called Party 

Number. 

NOTE 3: Basic when the full Called Party Number received in VPLMN or HPLMN is transferred on its own in the 
AssistRequestlnstructions operation CorrelationID parameter to a gsmSCF in HPLMN. 
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Bilateral when CorrelationID is extracted from Called Party Number in HPLMN or VPLMN and transferred 
on its own in AssistRequestlnstructions CorrelationID field to a gsmSCF in HPLMN. 

NOTE 4: Bilateral for the playing of announcements via elementaryMessagelDs and variableMessages, playing of 
tones and the collection of DTMF digits. 

NOTE 5: Basic for the playing of announcements via elementaryMessagelDs and variableMessages, playing of tones 
and the collection of DTMF digits. 

NOTE 6: Bilateral for the playing of announcements via text to speech translation, translation of DTMF digits via 
speech to caller and the translation of voice to digits. 



4.1 .3 CAP protocol architecture 



Many of the terms used in the present subclause are based on the OSI application layer structure as defined in ISO 9545 
(1989) [81]. 

The CAP protocol architecture is illustrated in figure 4-2. 

A Physical Entity (PE) has either single interactions (case a) or multiple co-ordinated interactions (case b) with another 
PE. 

In case (a), SACF provides a co-ordination function in using Application Service Elements (ASEs), which includes the 
ordering of operations supported by ASE(s), in the order of received primitives. The Single Association Object (SAO) 
represents the SACF plus a set of ASEs to be used over a single interaction between a pair of PEs. 

In case (b), MACF provides a co-ordinating function among several S AO's, each of which interacts with an SAO in a 
remote PE. 

Each ASE supports one or more operations. Description of each operation is tied with the action of corresponding 
Functional Entity (FE) modelling. For FE modelling, refer to ITU-T Recommendation Q. 1224 [50] and clause 1 1 of the 
present document. Each operation is specified using the OPERATION macro described in figure 4-3. 



Multiple coordinated interactions 
caseb 



SAO 



Application process 



MACF 




SAO 



SCCP 



Single interaction 
case a 





Application process 


Sj 


\o 






S 
A 


A 
S 

E's 




I 




TCAP 



SCCP 



MTP 



MTP 



NOTE: CAP is the collection of all specifications in ASEs. 

Figure 4-2: CAP protocol architecture 
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INAPUserASEs 

xyz OPERATION 

ARGUMENT {ParameteM , Parameter,...} 
RESULT {ParameteM , Parameter,...} 
LINKED {operation3, operation4,...} 
ERRORS {erroM, error2....} 

erroM ERROR 

PARAMETER {Parameter6, Parameter?,...} 
etc 



to peer 



Operations 

Results 

Errors 



TCAP ASE 



COMPONENT SUB-LAYER 



TRANSACTION SUB-LAYER 



to peer 



to peer 



T 



INVOKE 

RETURN RESULT 
RETURN ERROR 
REJECT 

BEGIN 

CONTINUE 

END 

ABORT 

UNIDIRECTIONAL 



CONNECTIONLESS SCCP 

Figure 4-3: Operation description 



4.1 .4 Compatibility mechanisms used for CAP 



4.1.4.1 



Introduction 



The present subclause specifies the compatibility mechanisms that shall be used for CAP. 

Two major categories of compatibility are handled by these mechanisms: 

compatibility with the ITU-T Recommendation Q.1228 [51] version of CS2 INAP and the specification EN 301 
140-1 version of CS2 INAP [26]; 

compatibility with future versions of CAP. 

The second category has three subcategories of compatibility dealt with within the present subclause: 

Minor changes to CAP in future versions of CAP: 

A minor change can be defined as a change of a functionality which is not essential for the requested IN service. 
Where it is a modification of an existing function, it is acceptable that the addressed function is executed in 
either the older or the modified variant. If the change is purely additional, then it is acceptable that it is not 
executed at all and that the peer Application Entity ( AE) need not know about the effects of the change. For 
minor changes, a new Application Context is not required. 

Major changes to CAP in future versions of CAP: 

A major change can be defined as a change of a functionality which is essential for the requested IN service. 
Where it is a modification of an existing function, both application entities shall have a shared knowledge about 
the addressed functional variant. If the change is purely additional and one of the application entities does not 
support the additional functionality, then the requested IN service will not be provided. For major changes, a 
new Application Context is required. 
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Network-specific changes to CAP: 

These additions may be of either the major or minor type for a service. No new Application Context is expected 
to be defined for this type of change. At the time of definition of these network-specific changes to CAP, the 
additions would not be expected to be included in identical form in future versions of CAP. 

4.1 .4.2 Definition of CAP compatibility mechanisms 

4.1 .4.2.1 Compatibility mechanism for interworking of CAP with ETSI CS2 Core INAP and 
ITU-T Q.1 228 INAP 

On receipt of an operation according to ITU-T Recommendation Q.1228 [51] or an operation according to ETSI EN 
301 140-1 [26], which is not part of the CAP or is part of the CAP but which contains parameters which are not part of 
the CAP: 

the gsmSSF, gsmSCF, assisting gsmSSF and gsmSRF shall apply the normal error handling for unknown 
operations or parameters, i.e. the normal error handling procedures as specified in clause 10 shall be followed. 

Tagging of CAP additions to ITU-T Recommendation Q.1228 [51] and ETSI EN 301 140-1 [26] are specified from 50 
to 59. 

4.1 .4.2.2 Procedures for major additions to CAP 

In order to support the introduction of major functional changes, the protocol allows a synchronisation between the two 
applications with regard to which functionality is to be performed. This synchronisation takes place before the new 
function is invoked in either application entity, in order to avoid complicated fall-back procedures. 

4.1 .4.2.3 Procedures for minor additions to CAP 

The extension mechanism marker shall be used for future standardised minor additions to CAP. This mechanism 
implements extensions by including an "extensions marker" in the type definition. The extensions are expressed by 
optional fields that are placed after the marker. When an entity receives unrecognised parameters that occur after the 
extension marker, they are ignored. Refer to ITU-T Recommendation X.680 [53] for further details on the extension 
mechanism. 

4.1 .4.2.4 Procedures for inclusion of network specific additions to CAP 

This mechanism is based on the ability to explicitly declare fields of any type via the Macro facility in ASN.l at the 
outermost level of a type definition. It works by defining an "ExtensionField" that is placed within the type definition. 
This extension field is defined as a set of extensions, where an extension can contain any type. Each extension is 
associated with an identification that unambiguously identifies the extension. Refer to ITU-T Recommendation Q.1400 
[52] for a definition of this mechanism. 

4.1 .5 Definition and usage of LegID 
4.1.5.1 Definition of LegID 

In CAP V4, two types of LegID may be exchanged between the gsmSCF and the gsmSSF. These are: 

Sending Side LegID; and 

Receiving Side LegID. 

Sending Side LegID is always used in operations sent from the gsmSCF to the gsmSSF, and Receiving Side LegID is 
always used in operations sent from the gsmSSF to the gsmSCF. 
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4.1 .5.2 Allocation of LegID 

For all operations containing a LegID: 

LegID = 1 shall always refer to the Calling Party, more specifically that party in the call present when InitialDP 
is sent to the gsmSCF; 

LegID = 2 shall always refer to a Called Party, more specifically a party in the call created as a result of the 
InitialDP operation, followed by the Connect, Continue or Continue WithArgument operation. 

LegID > 2 shall always refer to a Called Party, more specifically a party in the call created as a result of the 
InitiateCallAttempt operation, followed by the Continue WithArgument operation. 

4.2 SACF/MACF rules 

4.2.1 Reflection of TC AC 

TC AC negotiation rules require that the proposed AC, if acceptable, is reflected in the first backwards message. 

NOTE: If the gsmSSF, gprsSSF or smsSSF provides an AC which is not acceptable to the gsmSCF, then an alternate 
AC shall not be returned. If the AC presented to the gsmSCF is not acceptable, then this is most probably due 
to an error in subscriber data provisioning or an error at the gsmSSF, gprsSSF or smsSSF. 

4.2.2 Sequential/parallel execution of operations 

In some cases it may be necessary to distinguish whether operations should be performed sequentially or in parallel 
(synchronised). Operations which may be synchronised are: 

charging operations; may be synchronised with any other operation(s). 

The method of indicating to the receiving entity that operations should be synchronised is to transmit these operations in 
a single TC message. If one of the operations identified above shall not be executed until the execution of another 
operation has progressed to a certain extent or has finished, then the sending PE shall control this by sending the 
operations in two separate TC messages. 

This method does not imply that all operations sent in a single TC message shall be executed simultaneously, but that 
where it could make sense to do so (in the situations identified above) the operations should be synchronised. 

In the case of inconsistency between the above-mentioned generic rules and the FE-specific rules, as specified in 
clause 9, the FE-specific rules take precedence over the generic rules. 



Common CAP Types 



5.1 Datatypes 



CAP-datatypes (itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) 
modules (3) cap-datatypes (52) version5{4)} 

DEFINITIONS IMPLICIT TAGS ::= BEGIN 

IMPORTS 

Duration, 

Integer4 , 

Interval, 

LegID, 

ServiceKey 
FROM CSl-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) inDomain(l) in-network (1) 
modules(O) csl-datatypes (2) versionl(O)} 

BothwayThroughConnectionlnd, 
CriticalityType, 
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MiscCalllnfo 
FROM CS2-datatypes {itu-t(O) identif ied-organization (4) etsi(0) inDomain(l) in-network (1) 
cs2(20) modules (0) in-cs2-datatypes (0) versionl(O)} 

AddressString, 

CellGloballdOrServiceArealdFixedLength, 

Ext-BasicServiceCode , 

IMSI, 

ISDN- AddressString, 

LAIFixedLength, 

NAEA-CIC 
FROM MAP-CommonDataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-CommonDataTypes (18) version9(9)} 

Ext - QoS - Subscribed , 

Ext2-QoS- Subscribed, 

Ext 3 -QoS -Subscribed, 

Geographical Information, 

GSN-Address, 

Locationlnformation, 

LSAIdentity, 

QoS -Subscribed, 

RAIdentity, 

SubscriberState, 

GPRSChargingID 
FROM MAP-MS-DataTypes {itu-t(O) identif ied-organization (4 ) etsi{0) mobileDomain (0) 
gsm-Network (1) modules(3) map-MS-DataTypes (11) version9(9)} 

CallRef erenceNumber, 

Suppress ionOf Announcement 
FROM MAP-CH-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules{3) map-CH-DataTypes (13) version9(9)} 

tc-Messages, 

classes 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

EXTENSION, 
PARAMETERS - BOUND , 
Support edExt ens ions 
FROM CAP-classes classes 

ExtensionContainer 
FROM MAP-ExtensionDataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-ExtensionDataTypes (21) version9(9)} 



AccessPointName { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. StminAccessPointNameLength . . bound. kmaxAccessPointNameLength) ) 
-- Indicates the AccessPointName, refer to 3GPP TS 24.008 [9] for the encoding. 
-- It shall be coded as in the value part defined in 3GPP TS 24.008, 
-- i.e. the 3GPP TS 24.008 IEI and 3GPP TS 24.008 octet length indicator 
-- shall not be included. 

AChBillingChargingCharacteristics { PARAMETERS - BOUND : bound} :: = OCTET STRING (SIZE 
(bound. &minAChBillingChargingLength . . bound. kmaxAChBillingChargingLength) ) 
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of the type -- 
CAMEL-AChBillingChargingCharacteristics {bound} } ) 
-- The AChBillingChargingCharacteristics parameter specifies the charging related information 
-- to be provided by the gsmSSF and the conditions on which this information has to be reported 
-- back to the gsmSCF with the ApplyChargingReport operation. The value of the 

-- AChBillingChargingCharacteristics of type OCTET STRING carries a value of the ASN.l data type: 
-- CAMEL-AChBillingChargingCharacteristics . The normal encoding rules are used to encode this 
-- value. 
-- The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 

AChChargingAddress { PARAMETERS - BOUND : bound} ::= CHOICE { 
legID [2] LegID, 

srf Connection [50] CallSegmentID {bound} 
} 

AdditionalCallingPartyNumber { PARAMETERS - BOUND : bound} ::= Digits {bound} 
-- Indicates the Additional Calling Party Number. 

AlertingPattern ::= OCTET STRING (SIZE(3)) 

-- Indicates a specific pattern that is used to alert a subscriber 
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(e.g. distinctive ringing, tones, etc.). 

The encoding of the last octet of this parameter is as defined in 3GPP TS 29.002 [11] 
Only the trailing OCTET is used, the remaining OCTETS shall be sent as NULL (zero) 
The receiving side shall ignore the leading two OCTETS. 



AOCBeforeAnswer : : 
aOCInitial 
aOCSubsequent 



SEQUENCE 



[0] CAI-GSM0224, 
[1] AOCSubsequent 



OPTIONAL 



AOCGPRS : : = SEQUENCE 
aOCInitial 
aOCSubsequent 



[0] CAI-GSM0224, 
[1] AOCSubsequent 



OPTIONAL 



AOCSubsequent ; : = SEQUENCE 
CAI-GSM0224 
tariff Switchlnterval 



[0] CAI-GSM0224 , 

[1] INTEGER (1. .86400) 



OPTIONAL 



-- tariff Switchlnterval is measured in 1 second units 

AppendFreeFormatData : : = ENUMERATED { 
overwrite (0) , 
append (1) 



ApplicationTimer ::=INTEGER (0..2047) 

-- Used by the gsmSCF to set a timer in the gsmSSF. The timer is in seconds. 

AssistingSSPIPRoutingAddress { PARAMETERS - BOUND : bound} ::= Digits {bound} 
-- Indicates the destination address of the gsmSRF for the assist procedure. 



Audiblelndicator ::= CHOICE { 
tone 
burstList 



BOOLEAN, 
[1] BurstList 



} 



BackwardServicelnteractionlnd ::= SEQUENCE { 

conferenceTreatmentlndicator [1] OCTET STRING (SIZE(l)) 

-- acceptConf erenceRequest 'xxxx xxOl'B 

-- rejectConf erenceRequest 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument , 

-- then CAMEL service does not affect conference treatement 

callCompletionTreatmentlndicator [2] OCTET STRING (SIZE(l)) 

-- acceptCallCompletionServiceRequest 'xxxx xxOl'B, 

-- rejectCallCompletionServiceRequest 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument, 

-- then CAMEL service does not affect call completion treatment 



OPTIONAL, 



OPTIONAL, 



BasicGapCriteria { PARAMETERS - BOUND 
calledAddressValue 
gapOnService 
calledAddressAndService 

calledAddressValue 

serviceKey 



bound} : := CHOICE { 

[0] Digits {bound}, 
[2] GapOnService, 
[29] SEQUENCE { 

[0] Digits {bound} 
[1] ServiceKey, 



callingAddressAndService 
callingAddressValue 
serviceKey 



[3 0] SEQUENCE { 

[0] Digits {bound} 
[1] ServiceKey, 



Both calledAddressValue and callingAddressValue can be 

incomplete numbers, in the sense that a limited amount of digits can be given. 

For the handling of numbers starting with the same digit string refer to the detailed 

procedure of the CallGap operation 



BCSMEvent { PARAMETERS - BOUND 
eventTypeBCSM 
monitorMode 
legID 

dpSpecif icCriteria 
automat icRearm 



bound} ::= SEQUENCE { 

[0] EventTypeBCSM, 

[1] MonitorMode, 

[2] LegID 

[30] DpSpecif icCriteria 

[50] NULL 



bound } 



OPTIONAL, 
OPTIONAL, 

OPTIONAL, 
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-- Indicates the BCSM Event information for monitoring. 

BCSM-Failure { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

legID [0] LegID 

cause [2] Cause {bound} 



OPTIONAL, 
OPTIONAL, 



BearerCapability 
bearerCap 



PARAMETERS - BOUND 



bound} 

[0] 



: := CHOICE { 

OCTET STRING (SIZE (2 .. bound . kmaxBearerCapabilityLength) ) 



Indicates the type of bearer capability connection to the user. For bearerCap, 
Service Information, ETSI EN 300 356-1 [23] 
encoding shall be used. 



the ISUP User 



Burst : : = SEQUENCE { 
numberOf Bursts 
bur st Interval 
numberOf Tone slnBur st 
toneDuration 
tonelnterval 



[0] 


INTEGER 


(1. 


.3) 


DEFAULT 


1 


[1] 


INTEGER 


(1. 


.1200) 


DEFAULT 


2 


[2] 


INTEGER 


(1. 


.3) 


DEFAULT 


3 


[3] 


INTEGER 


(1. 


.20) 


DEFAULT 


2 


[4] 


INTEGER 


(1. 


.20) 


DEFAULT 


2 



burstlnterval, toneDurartion and tonelnterval are measured in 100 millisecond units 



BurstList ::= SEQUENCE 
warningPeriod 
bursts 



[0] INTEGER (1..1200) DEFAULT 30, 
[1] Burst, 



warningPeriod is measured in 1 second units. 



CAI-GSM0224 
el 
e2 
e3 
e4 
e5 
e6 
e7 



SEQUENCE 



[0] 


INTEGER 





.8191) 


[1] 


INTEGER 





.8191) 


[2] 


INTEGER 





.8191) 


[3] 


INTEGER 





.8191) 


[4] 


INTEGER 





.8191) 


[5] 


INTEGER 





.8191) 


[6] 


INTEGER 





.8191) 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL 



-- Indicates Charge Advice Information to the Mobile Station. For information regarding 
-- parameter usage, refer to 3GPP TS 22.024 [2] . 

CalledPartyBCDNumber { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminCalledPartyBCDNumberLength . . bound. kmaxCalledPartyBCDNumberLength) ) 

-- Indicates the Called Party Number, including service selection information. 

-- Refer to 3GPP TS 24.008 [9] for encoding. 

-- This data type carries only the 'type of number 1 , 'numbering plan 

-- identification' and 'number digit' fields defined in 3GPP TS 24.008 [9] ; 

-- it does not carry the 'called party BCD number IEI ' or 'length of called 

-- party BCD number contents'. 

-- In the context of the DestinationSubscriberNumber field in ConnectSMSArg or 

-- InitialDPSMSArg, a CalledPartyBCDNumber may also contain an alphanumeric 

-- character string. In this case, type-of -number '101'B is used, in accordance 

-- with 3GPP TS 23.040 [6] . The address is coded in accordance with the 

-- GSM 7-bit default alphabet definition and the SMS packing rules 

-- as specified in 3GPP TS 23.038 [15] in this case. 

CalledPartyNumber { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminCalledPartyNumberLength . . bound. kmaxCalledPartyNumberLength) ) 
-- Indicates the Called Party Number. Refer to ETS EN 300 356-1 [23] for encoding. 

-- A CalledPartyNumber may contain national-specific values of the Nature Of Address 

-- indicator. The filling-in of the national-specific Nature Of Address indicator 

-- values shall be done in accordance with the national ISUP of the gsmSSF country, e.g. 

-- ANSI Tl. 113-1995 [92] . 

-- In terms of ETS EN 300 356-1 [23] , the Destination Address Field is not present if the 

-- destination address length is set to zero. This is the case e.g. when the ANSI 

-- ISUP Nature Of Address indicator indicates no number present, operator requested 

-- (1110100) or no number present, cut-through call to carrier (1110101) . 

-- See also see 3GPP TS 23.078 [7] . 

CallingPartyNumber { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminCallingPartyNumberLength . . bound. kmaxCallingPartyNumberLength) ) 
-- Indicates the Calling Party Number. Refer to ETSI EN 300 356-1 [23] for encoding. 

CallResult { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 
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bound. SminCallResultLength .. bound. SmaxCallResultLength) ) 

(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type - 
CAMEL-CallResult {bound}}) 
The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 



This parameter provides the gsmSCF with the charging related information previously requested 
using the ApplyCharging operation. This shall include the partyToCharge parameter as 
received in the related ApplyCharging operation to correlate the result to the request 



CallSegmentFailure { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

callSegmentID [0] CallSegmentID {bound} 

cause [2] Cause {bound} 



OPTIONAL, 
OPTIONAL, 



CallSegmentID { PARAMETERS - BOUND : bound} 



INTEGER (1. .bound. knumOfCSs) 



CallSegmentToCancel { PARAMETERS - BOUND : bound} ::= SEQUENCE { 
invokelD [0] InvokelD 

callSegmentID [1] CallSegmentID {bound} 



OPTIONAL, 
OPTIONAL, 



CAMEL-AChBillingChargingCharacteristics { PARAMETERS - BOUND : bound} 



CHOICE { 



timeDurationCharging 

maxCallPeriodDuration 
releaselfdurationExceeded 
tariff Switchlnterval 
audible Indicator 
extensions 



[0] SEQUENCE { 

[0] INTEGER (1.. 864000), 

[1] BOOLEAN DEFAULT FALSE, 

[2] INTEGER (1. .86400) 

[3] Audiblelndicator DEFAULT tone: 

[4] Extensions {bound} 



OPTIONAL, 
FALSE , 
OPTIONAL, 



tariff Switchlnterval is measured in 1 second units. 
maxCallPeriodDuration is measured in 100 millisecond units 



CAMEL-CallResult { PARAMETERS - BOUND : bound} 



timeDurationChargingResult 
partyToCharge 
time Information 
legActive 

callLegReleasedAtTcpExpiry 
extensions 
aChChargingAddress 



[0] 



: := CHOICE { 
SEQUENCE { 
[0] ReceivingSidelD, 
[1] Timelnformation, 
[2] BOOLEAN DEFAULT TRUE, 
[ 3 ] NULL 

[4] Extensions {bound} 
[5] AChChargingAddress {bound} 



OPTIONAL, 
OPTIONAL, 



DEFAULT legID : receivingSidelD : legl , 



} 

CAMEL-FCIBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ::= CHOICE{ 
fCIBCCCAMELsequencel [0] SEQUENCE { 

freeFormatData [0] OCTET STRING <SIZE< 

bound. &minFCIBillingChargingDataLength . . bound. kmaxFCIBillingChargingDataLength) ) 
partyToCharge [1] SendingSidelD DEFAULT sendingSidelD ; legl, 

appendFreeFormatData [2] AppendFreeFormatData DEFAULT overwrite, 

}" 
} 

CAMEL-FCIGPRSBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ::= SEQUENCE{ 
fCIBCCCAMELsequencel [0] SEQUENCE { 

freeFormatData [0] OCTET STRING (SIZE( 

bound. &minFCIBillingChargingDataLength . . bound. kmaxFCIBillingChargingDataLength) ) 
pDPID [1] PDPID OPTIONAL, 

appendFreeFormatData [2] AppendFreeFormatData DEFAULT overwrite, 

}" 

} 

CAMEL-FCISMSBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ::= CHOICE{ 
fCIBCCCAMELsequencel [0] SEQUENCE { 

freeFormatData [0] OCTET STRING <SIZE< 

bound. &minFCIBillingChargingDataLength . . bound. kmaxFCIBillingChargingDataLength) ) 
appendFreeFormatData [1] AppendFreeFormatData DEFAULT overwrite 



} 
CAMEL-SCIBillingChargingCharacteristics ::= CHOICE 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 



33 



ETSI TS 129 078 V8.2.1 (2010-04) 



aOCBef oreAnswer 
aOCAf terAnswer 
aOC- extension 



[0] AOCBeforeAnswer, 

[1] AOCSubsequent, 

[2] CAMEL- SCIBillingChargingCharacteristicsAlt 



CAMEL-SCIBillingChargingCharacteristicsAlt ::= SEQUENCE { 



This datatype is for extension in future releases. 

CAMEL-SCIGPRSBillingChargingCharacteristics ::= SEQUENCE 
aOCGPRS [0] AOCGPRS, 

pDPID [1] PDPID 



OPTIONAL, 



Carrier { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE{ 

bound. kminCarrierLength .. bound. SmaxCarrierLength) ) 
-- This parameter is used for North America (na) only. 

-- It contains the carrier selection field (first octet) followed by Carrier ID 
-- information (North America (na) ) . 



The Carrier 

00000000 
00000001 

00000010 

00000011 

00000100 

00000101 

to 
11111110 

11111111 



selection is one octet and is encoded as: 
No indication 

Selected carrier identification code (CIC) pre subscribed and not 
input by calling party 

Selected carrier identification code (CIC) pre subscribed and input by 
calling party 

Selected carrier identification code (CIC) pre subscribed, no 
indication of whether input by calling party (undetermined) 
Selected carrier identification code (CIC) not pre subscribed and 
input by calling party 

Spare 

Reserved 



-- Refer to ANSI Tl. 113-1995 [92] for encoding of na carrier ID information (3 octets) 

Cause {PARAMETERS -BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminCauseLength .. bound. SmaxCauseLength) ) 
-- Indicates the cause for interface related information. 
-- Refer to ETSI EN 300 356-1 [23] Cause parameter for encoding. 

-- For the use of cause and location values refer to ITU-T Recommendation Q.850 [47] 
-- Shall always include the cause value and shall also include the diagnostics field, 
-- if available. 



CGEncountered ; ; = ENUMERATED { 
noCGencountered 
manualCGencountered 
scpOverload 



(0) 



(1) , 



(2) 



-- Indicates the type of automatic call gapping encountered, if any. 

ChangeOfPositionControlInfo { PARAMETERS - BOUND : bound} ::= SEQUENCE SIZE 
(1 . .bound. &numOf ChangeOf PositionControlInfo) OF ChangeOfLocation {bound} 



ChangeOf Location { PARAMETERS - BOUND 
cellGloballd 
serviceAreald 
locationAreald 
inter- SystemHandOver 
inter- PLMNHandOver 
inter-MSCHandOver 
changeOfLocationAlt 



bound} : := CHOICE { 

[0] CellGloballdOrServiceArealdFixedLength, 
[1] CellGloballdOrServiceArealdFixedLength, 
[2] LAIFixedLength, 
[ 3 ] NULL , 
[4] NULL, 
[ 5 ] NULL , 
[6] ChangeOfLocationAlt {bound} 



} 



The cellGloballd shall contain a Cell Global Identification. 
The serviceAreald shall contain a Service Area Identification. 



ChangeOfLocationAlt { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

}" 

Chargelndicator ::= OCTET STRING (SIZE (1)) 

As specified in ITU-T Recommendation Q.763 as follows: 
no indication 'xxxx xxOO'B 
no charge 'xxxx xxOl'B 
charge 'xxxx xxlO'B 
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spare 'xxxx xxll'B 

Sending entity shall fill the upper six bits with '0's. 
Receiving entity shall ignore the upper six bits. 

ChargeNumber { PARAMETERS - BOUND : bound} ::= LocationNumber {bound} 

-- Information sent in either direction indicating the chargeable number for the call and 

-- consisting of the odd/even indicator, nature of address indicator, numbering plan indicator, 

-- and address signals. 

-- Uses the LocationNumber format which is based on the Location Number format as defined 

--in ITU-T Recommendation Q.763 [45] . 

-- For example, the ChargeNumber may be a third party number to which a call is billed for 

-- the 3rd party billing service. In this case, the calling party may request operator assistance 

-- to charge the call to, for example, their home number. 

-- For NA, this parameter uniquely identifies the chargeable number for a call sent into a North 
-- American long distance carrier. It transports the ChargeNumber Parameter Field as defined in 
-- ANSI Tl. 113-1995 [92]. This provides 

- 1 octet for the nature of address indicator field, plus 

- 1 octet for a numbering plan field, plus 

- up to 5 octets for the address signal (up to 10 digits) 

-- The Charge Number in ANSI Tl. 113-1995 [92] normally contains a 10 digit national number within 
-- the North American Numbering Plan (NANP) ; longer (e.g. international) charge numbers are not 
-- supported in ANSI Tl. 113-1995 [92] . 



ChargingCharacteristics : 
maxTransf erredVolume 
maxElapsedTime 



CHOICE { 



[0] INTEGER (1. .4294967295) 
[1] INTEGER (1. .86400) 



maxTransf erredVolume is measured in number of bytes 
maxElapsedTime is measured in seconds 



ChargingResult ::= CHOICE { 
trans f erredVolume 
elapsedTime 



[0] Transf erredVolume, 
[1] ElapsedTime 



ChargingRollOver ::= CHOICE { 
transf erredVolumeRollOver 
elapsedTimeRollOver 



[0] Transf erredVolumeRollOver, 
[1] ElapsedTimeRollOver 



transf"erredVolumeJ?ollOver shall be reported if ApplyChargingReportGPRS reports volume and 
a roll-over has occurred in one or more volume counters. Otherwise, it shall be absent. 
elapsedTimeRollOver shall be reported if ApplyChargingReportGPRS reports duration and 
a roll-over has occurred in one or more duration counters. Otherwise, it shall be absent. 



CollectedDigits ::= SEQUENCE { 
minimumNbOf Digits 
maximumNbOf Digits 
endOfReplyDigit 
cancelDigit 
startDigit 
f irstDigitTimeOut 
interDigitTimeOut 
errorTreatment 
interrupt ableAnnlnd 
voicelnformation 
voiceBack 



[0] INTEGER (1..30) DEFAULT 1, 
[1] INTEGER (1. .30) , 
[2] OCTET STRING (SIZE (1..2)) 
[3] OCTET STRING (SIZE (1..2)) 
[4] OCTET STRING (SIZE (1..2)) 
[5] INTEGER (1. .12 7) 
[6] INTEGER (1. .12 7) 

[7] ErrorTreatment DEFAULT stdErrorAndlnf o, 
BOOLEAN DEFAULT TRUE, 
[9] BOOLEAN DEFAULT FALSE, 
[10] BOOLEAN DEFAULT FALSE 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



-- The use of voiceBack and the support of voice recognition via voicelnformation 

-- is network operator specific. 

-- The endOfReplyDigit, cancelDigit, and startDigit parameters have been 

-- designated as OCTET STRING, and are to be encoded as BCD, one digit per octet 

-- only, contained in the four least significant bits of each OCTET. The following encoding shall 

--be applied for the non-decimal characters: 

-- 1011 (*) , 1100 (#) . 

-- The usage is service dependent. 

-- f irstDigitTimeOut and interDigitTimeOut are measured in seconds. 



Collectedlnfo ::= CHOICE 
CollectedDigits 



[0] CollectedDigits 



ConnectedNumberTreatmentlnd ::= ENUMERATED ■ 

noINImpact (0) , 

presentationRestricted (1) , 

presentCalledlNNumber (2), 
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presentCalllNNumberRestricted (3) 

} 

-- This parameter is used to suppress or to display the connected number. 

ControlType ; ; = ENUMERATED { 

sCPOverloaded (0) , 

manuallylnitiated (1) 

} 

CompoundCriteria { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

basicGapCriteria [0] BasicGapCriteria {bound}, 

scfID [1] ScfID {bound} OPTIONAL 

} 

CorrelationID { PARAMETERS - BOUND : bound} ::= Digits {bound} 
-- used by gsmSCF for correlation with a previous operation. 

DateAndTime ::= OCTET STRING (SIZE (7)) 

DateAndTime is BCD encoded. The year digit indicating millenium occupies bits 

0-3 of the first octet, and the year digit indicating century occupies bits 

4-7 of the first octet. 

The year digit indicating decade occupies bits 0-3 of the second octet, 

whilst the digit indicating the year within the decade occupies bits 4-7 of 

the second octet. 

The most significant month digit occupies bits 0-3 of the third octet, 

and the least significant month digit occupies bits 4-7 of the third octet. 

The most significant day digit occupies bits 0-3 of the fourth octet, 

and the least significant day digit occupies bits 4-7 of the fourth octet. 

The most significant hours digit occupies bits 0-3 of the fifth octet, 

and the least significant digit occupies bits 4-7 of the fifth octet. 

The most significant minutes digit occupies bits 0-3 of the sixth octet, 

and the least significant digit occupies bits 4-7 of the sixth octet. 

The most significant seconds digit occupies bits 0-3 of the seventh octet, 

and the least seconds significant digit occupies bits 4-7 of the seventh octet. 

For the encoding of digits in an octet, refer to the timeAndtimezone parameter. 

DestinationRoutingAddress { PARAMETERS - BOUND : bound} ::= SEQUENCE SIZE{1) OF 

CalledPartyNumber {bound} 
-- Indicates the Called Party Number. 

Digits {PARAMETERS -BOUND : bound} ;:= OCTET STRING (SIZE( 

bound. kminDigitsLength .. bound. SmaxDigitsLength) ) 
-- Indicates the address signalling digits. 

-- Refer to ETSI EN 300 356-1 [23] Generic Number & Generic Digits parameters for encoding. 
-- The coding of the subfields ' NumberQualif ier ' in Generic Number and ' TypeOf Digits ' in 
-- Generic Digits are irrelevant to the CAP; 
-- the ASN.l tags are sufficient to identify the parameter. 
-- The ISUP format does not allow to exclude these subfields, 
-- therefore the value is network operator specific. 

-- The following parameters shall use Generic Number: 

- AdditionalCallingPartyNumber for InitialDP 

- AssistingSSPIPRoutingAddress for EstablishTemporaryConnection 

- CorrelationID for AssistRequestlnstructions 

- CalledAddressValue for all occurrences, CallingAddressValue for all occurrences. 

-- The following parameters shall use Generic Digits: 

- CorrelationID in EstablishTemporaryConnection 

- number in VariablePart 

- digitsResponse in Receivedlnf ormationArg 

- midCallEvents in oMidCallSpecif iclnfo and tMidCallSpecif iclnfo 

-- In the digitsResponse and midCallevents, the digits may also include the '*', '#', 

-- a, b, c and d digits by using the IA5 character encoding scheme. If the BCD even or 

-- BCD odd encoding scheme is used, then the following encoding shall be applied for the 

-- non-decimal characters: 1011 {*), 1100 {#) . 

-- AssistingSSPIPRoutingAddress in EstablishTemporaryConnection and CorrelationID in 
-- AssistRequestlnstructions may contain a Hex B digit as address signal. Refer to 
-- Annex A. 6 for the usage of the Hex B digit. 

-- Note that when CorrelationID is transported in Generic Digits, then the digits shall 
-- always be BCD encoded. 

DpSpecificCriteria { PARAMETERS - BOUND : bound} ::= CHOICE { 

applicationTimer [1] ApplicationTimer, 

midCallControlInfo [2] MidCallControlInf o, 

dpSpecif icCriteriaAlt [3] DpSpecif icCriteriaAlt {bound} 
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Exception handling: reception of DpSpecif icCriteriaAlt shall be treated like 

reception of no DpSpecif icCriteria . 

The gsmSCF may set a timer in the gsmSSF for the No_Answer event. 

If the user does not answer the call within the allotted time, 

then the gsmSSF reports the event to the gsmSCF. 

The gsmSCF may define a criterion for the detection of DTMF digits during a call. 

The gsmSCF may define other criteria in the dpSpecif icCriteriaAlt alternative 

in future releases. 



DpSpecif icCriteriaAlt { PARAMETERS - BOUND : bound} 



SEQUENCE 



changeOf Posit ionControl Info 
numberOf Digits 
interDigitTimeout 

} 
interDigitTimeout 



[0] ChangeOf PositionControlInfo {bound} 
[1] NumberOfDigits 
[2] INTEGER (1, .127) 

duration in seconds. 



OPTIONAL, 
OPTIONAL 



DpSpecif icInfoAlt { PARAMETERS - BOUND : bound} 



SEQUENCE 



oServiceChangeSpeci fie Info 
ext-basicServiceCode 



[0] SEQUENCE { 

[0] Ext-BasicServiceCode 



OPTIONAL, 



initiatorOf ServiceChange 
natureOf ServiceChange 



[1] InitiatorOf ServiceChange 
[2] NatureOf ServiceChange 



OPTIONAL, 
OPTIONAL 



tServiceChangeSpeci fie Info 
ext-basicServiceCode 



[1] SEQUENCE { 

[0] Ext-BasicServiceCode 



OPTIONAL, 



initiatorOf ServiceChange 
natureOf ServiceChange 



[1] InitiatorOf ServiceChange 
[2] NatureOf ServiceChange 



OPTIONAL, 
OPTIONAL 



col lee tedlnf oSpeci fie Info 
calledPartyNumber 



[2] SEQUENCE { 

[0] CalledPartyNumber 



OPTIONAL, 



} 

This datatype is for extension in future releases. 



ElapsedTime ::= CHOICE { 

timeGPRSIfNoTariff Switch 
timeGPRSIf Tariff Switch 

timeGPRSSinceLastTariff Switch 
timeGPRSTarif fSwitchlnterval 



[0] INTEGER (0 . .86400) , 

[1] SEQUENCE { 

[0] INTEGER (0 . .86400) 
[1] INTEGER (0 . .86400) 



OPTIONAL 



timeGPRSIfNoTariff Switch is measured in seconds 

timeGPRSSinceLastTariff Switch and timeGPRSTarif fSwitchlnterval are measured in seconds 



ElapsedTimeRollOver ::= CHOICE { 

rO-TimeGPRSIfNoTariffSwitch [0] INTEGER (0..255), 

rO-TimeGPRSIfTariffSwitch [1] SEQUENCE { 

rO-TimeGPRSSinceLastTariffSwitch [0] INTEGER (0..255) 

rO-TimeGPRSTariffSwitchlnterval [1] INTEGER (0..255) 



OPTIONAL, 
OPTIONAL 



rO-TimeGPRSIfNoTariff Switch, rO-TimeGPRSSinceLastTariff Switch and 

rO- TimeGPRSTarif fSwitchlnterval 

present counters indicating the number of parameter range rollovers. 



EndUserAddress { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

pDPTypeOrganization [0] OCTET STRING (SIZE(l)), 

pDPTypeNumber [1] OCTET STRING (SIZE(l)), 

pDPAddress [2] OCTET STRING <SIZE< 

bound. kminPDPAddressLength .. bound. kmaxPDPAddressLength) ) 



OPTIONAL 



Indicates the EndUserAddress, refer to 3GPP TS 29.060 [12] for the encoding. 
The pDPTypeOrganization shall use the least significant 4 bits of the octet encoded. 
The sender of this parameter shall set the most significant 4 bits of the octet to 1. 
The receiver of this parameter shall ignore the most significant 4 bits of this octet. 



ErrorTreatment ; ; = ENUMERATED { 
stdErrorAndlnfo 
help 
repeat Prompt 



(0) , 

(1) , 
(2) 



stdErrorAndlnf omeans returning the ' ImproperCallerResponse ' error in the event of an error 
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condition during collection of user info. 



EventSpecificInformationBCSM { PARAMETERS - BOUND : bound} ::= CHOICE { 
routeSelectFailureSpecif iclnfo [2] SEQUENCE { 

failureCause [0] Cause {bound} 



OPTIONAL, 



oCalledPartyBusySpec if iclnfo 
busyCause 



[3] SEQUENCE { 

[0] Cause {bound} 



OPTIONAL, 



oNoAnswerSpecif iclnfo [4] SEQUENCE { 

--no specific info defined -- 



oAnswerSpec if iclnfo 

destinationAddress 

or-Call 

forwardedCall 

charge Indicator 

ext-basicServiceCode 

ext-basicServiceCode2 



[5] SEQUENCE { 

[50] CalledPartyNumber {bound} 

[51] NULL 

[52] NULL 

[53] Chargelndicator 

[54] Ext-BasicServiceCode 

[55] Ext-BasicServiceCode 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



oMidCallSpec if iclnfo 
midCallEvents 

dTMFDigitsCompleted 

dTMFDigitsTimeOut 

} 



[6] SEQUENCE { 

[1] CHOICE { 

[3] Digits {bound}, 
[4] Digits {bound} 



OPTIONAL, 



oDisconnect Spec if iclnfo 
releaseCause 



[7] SEQUENCE { 

[0] Cause {bound} 



OPTIONAL, 



tBusySpec if iclnfo 
busyCause 
callForwarded 
rout eNot Permit ted 
forwardingDestinationNumber 

}," 

tNoAnswerSpec if iclnfo 

callForwarded 
forwardingDestinationNumber 



[8] SEQUENCE { 

[0] Cause {bound} 

[50] NULL 

[51] NULL 

[52] CalledPartyNumber {bound} 



[9] SEQUENCE { 

[50] NULL 
[52] CalledPartyNumber {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



OPTIONAL, 
OPTIONAL, 



tAnswerSpec if iclnfo 

destinationAddress 

or-Call 

forwardedCall 

chargelndicator 

ext-basicServiceCode 

ext-basicServiceCode2 



[10] SEQUENCE { 

[50] CalledPartyNumber {bound} 

[51] NULL 

[52] NULL 

[53] Chargelndicator 

[54] Ext-BasicServiceCode 

[55] Ext-BasicServiceCode 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



tMidCallSpecif iclnfo 
midCallEvents 

dTMFDigitsCompleted 
dTMFDigitsTimeOut 



[11] SEQUENCE { 
[1] CHOICE { 

[3] Digits {bound}, 
[4] Digits {bound} 



OPTIONAL, 



tDisconnect Spec if iclnfo 
releaseCause 



[12] SEQUENCE { 

[0] Cause {bound} 



OPTIONAL, 



oTermSeizedSpecif iclnfo 
locationlnf ormation 



[13] SEQUENCE { 

[50] Locationlnformation 



OPTIONAL, 



callAcceptedSpec if iclnfo 
locationlnformation 



[20] SEQUENCE { 

[50] Locationlnformation 



OPTIONAL, 



oAbandonSpec if iclnfo 
rout eNot Permit ted 



[21] SEQUENCE { 
[50] NULL 



OPTIONAL, 
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oChangeOf Posit ionSpeci fie Info 
locationlnformation 

metDPCriteriaList 

}. 

tChangeOf Posit ionSpeci fie Info 
locationlnformation 



[5 0] SEQUENCE { 

[50] Locationlnformation 

[51] MetDPCriteriaList {bound} 

[51] SEQUENCE { 

[50] Locationlnformation 



[51] MetDPCriteriaList {bound} 
[52] DpSpecif icInfoAlt {bound} 



metDPCriteriaList 

}. 

dpSpecif icInfoAlt 

} 
-- Indicates the call related information specific to the event. 

EventSpecif idnformationSMS ;:= CHOICE { 



OPTIONAL, 
OPTIONAL 

OPTIONAL, 
OPTIONAL 



o-smsFailureSpeci fie Info 
f ailureCause 



[0] SEQUENCE { 
[0] MO-SMSCause 



OPTIONAL, 



o -smsSubmiss ionSpeci ficlnfo 

--no specific info defined- 



[1] SEQUENCE 



t-smsFailureSpeci fie Info 
f ailureCause 



[2] SEQUENCE { 
[0] MT-SMSCause 



OPTIONAL, 



t-smsDeliverySpeci fie Info 

--no specific info defined- 



[3] SEQUENCE 



EventTypeBCSM : : = ENUMERATED 
collectedlnf o 
analyzedlnformation 
rout eSelect Failure 
oCalledPartyBusy 
oNoAnswer 
oAnswer 
oMidCall 
oDisconnect 
oAbandon 

termAt tempt Authorized 
tBusy 
tNoAnswer 
tAnswer 
tMidCall 
tDisconnect 
tAbandon 
oTermSeized 
callAccepted 
oChangeOf Position 
tChangeOf Position 

oServiceChange 
tServiceChange 



(3) 



(2) , 

(4) , 

(5) , 

(6) , 

(7) , 

(8) , 
O) , 
(10) 
(12) 
(13) 
(14) 
(15) 
(16) 
(17) 
(18) 
(19) 
(27) 
(50) 
(51) 

(52) , 
(53) 



-- Indicates the BCSM detection point event. 

-- Values analyzedlnformation and termAttemptAuthorized may be used 

-- for TDPs only. 

-- Exception handling: reception of an unrecognized value shall be treated 

-- like reception of no detection point. 



EventTypeSMS ; : = ENUMERATED { 
sms-Collectedlnfo 
o-smsFailure 
o-smsSubmission 
sms-DeliveryRequested 
t-smsFailure 
t-smsDelivery 



(1) , 

(2) , 

(3) , 

(11) , 

(12) , 
(13) 



-- Values sms-Collectedlnfo and sms-DeliveryRequested may be used for TDPs only. 

Extensions { PARAMETERS - BOUND : bound} ::= SEQUENCE SIZE (1 .. bound . knumOf Extensions) OF 

ExtensionField 

ExtensionField ::= SEQUENCE { 
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type 

criticality 
value 



EXTENSION. &id ( { SupportedExtensions } ) , 
-- shall identify the value of an EXTENSION type 
CriticalityType DEFAULT ignore, 
[1] EXTENSION. &ExtensionType ( {SupportedExtensions } {@type} ) 



-- This parameter indicates an extension of an argument data type. 
-- Its content is network operator specific 

FCIBillingChargingCharacteristics { PARAMETERS - BOUND ; bound} ::= OCTET STRING <SIZE< 
bound. kminFCIBillingChargingLength . . bound. kmaxFCIBillingChargingLength) ) 
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type -- 
CAMEL-FCIBillingChargingCharacteristics {bound} } ) 

-- This parameter indicates the billing and/or charging characteristics. 

-- The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 

FCIGPRSBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ;:= OCTET STRING <SIZE< 
bound. kminFCIBillingChargingLength . . bound. kmaxFCIBillingChargingLength) ) 
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type - 
CAMEL-FCIGPRSBillingChargingCharacteristics {bound} } ) 

-- This parameter indicates the GPRS billing and/or charging characteristics. 

-- The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 

FCISMSBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 
bound. kminFCIBillingChargingLength . . bound. kmaxFCIBillingChargingLength) ) 
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type - 
CAMEL-FCISMSBillingChargingCharacteristics {bound} } ) 

-- This parameter indicates the SMS billing and/or charging characteristics. 

-- The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 

ForwardServicelnteractionlnd ::= SEQUENCE { 

conferenceTreatmentlndicator [1] OCTET STRING (SIZE(l)) OPTIONAL, 

-- acceptConf erenceRequest 'xxxx xxOl'B 

-- rejectConf erenceRequest 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument , 

-- then CAMEL service does not affect conference treatment 

callDiversionTreatmentlndicator [2] OCTET STRING (SIZE(l)) OPTIONAL, 

-- callDiversionAllowed 'xxxx xxOl'B 

-- callDiversionNotAllowed 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument, 

-- then CAMEL service does not affect call diversion treatment 

callingPartyRestrictionlndicator [4] OCTET STRING (SIZE(l)) OPTIONAL, 

-- noINImpact 'xxxx xxOl'B 

-- presentationRestricted 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument, 

-- then CAMEL service does not affect calling party restriction treatment 

} 



GapCriteria { PARAMETERS - BOUND 
basicGapCriteria 
compoundGapCriteria 



bound} : := CHOICE { 

BasicGapCriteria {bound} 
CompoundCriteria {bound} 



Gaplndicators : : 
duration 
gaplnterval 



SEQUENCE { 



[0] Duration, 
[1] Interval, 



Indicates the call gapping characteristics. 
No call gapping when gaplnterval equals . 



GapOnService : : 
serviceKey 



SEQUENCE { 



[0] ServiceKey, 



GapTreatment { PARAMETERS - BOUND 
informationToSend 
releaseCause 



bound} : := CHOICE { 

[0] InformationToSend 
[1] Cause {bound} 



bound} 



-- The default value for Cause is the same as in ISUP. 

GenericNumber { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminGenericNumberLength .. bound. kmaxGenericNumberLength) ) 
-- Indicates a generic number. Refer to ETSI EN 300 356-1 [23] Generic number for encoding. 
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GenericNumbers { PARAMETERS - BOUND 
GenericNumber {bound} 

GPRS-QoS ::= CHOICE { 
short - QoS - format 
long- QoS- format 



bound} ::= SET SIZE (1 .. bound . knumOf GenericNumbers) OF 



[0] QoS-Subscribed, 
[1] Ext-QoS-Subscribed 



Short-QoS-format shall be sent for QoS in pre GSM release 99 format. 

Long-QoS-format shall be sent for QoS in GSM release 99 (and beyond) format. 

Which of the two QoS formats shall be sent is determined by which QoS 

format is available in the SGSN at the time of sending. 

Refer to 3GPP TS 29.002 [11] for encoding details of QoS-Subscribed and 

Ext-QoS-Subscribed. 



GPRS-QoS-Extension ::= SEQUENCE { 
supplement -to -long- QoS -format 

additionalSupplement 



[0] Ext2-QoS-Subscribed, 

[1] Ext3-QoS-Subscribed 



OPTIONAL 



GPRSCause { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE 

(bound. SminGPRSCauseLength .. bound. kmaxGPRSCauseLength) ) 
-- Shall only include the cause value. 

00000000 Unspecified 

All other values shall be interpreted as 'Unspecified' . 

-- This parameter indicates the cause for CAP interface related information. 

-- The GPRSCause mapping to/from GTP cause values specified in the 3GPP TS 29.060 [12] and 

-- to/from 3GPP TS 24.008 [9] GMM cause and SM cause values are outside scope of this document. 



GPRSEvent : : = SEQUENCE 
gPRSEventType 
monitorMode 



[0] GPRSEventType, 
[1] MonitorMode 



Indicates the GPRS event information for monitoring. 

GPRSEventSpecificInformation { PARAMETERS - BOUND : bound} ::= CHOICE { 

at t achChangeOf Posit ionSpeci fie Information 

[0] SEQUENCE { 
locationlnformationGPRS [0] LocationlnformationGPRS 



OPTIONAL, 



pdp-ContextchangeOf Posit ionSpeci fie Information 



accessPointName 

chargingID 

locationlnformationGPRS 

endUserAddress 

qualityOf Service 

timeAndTimeZone 

gGSNAddress 
}. 

detachSpeci fie Information 
initiatingEntity 

routeingAreaUpdate 



[1] SEQUENCE { 

[0] AccessPointName {bound} 

[1] GPRSChargingID 

[2] LocationlnformationGPRS 

[3] EndUserAddress {bound} 

[4] QualityOfService 

[5] TimeAndTimezone {bound} 

[6] GSN-Address 



[2] SEQUENCE { 

[0] InitiatingEntity 

[1] NULL 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 

OPTIONAL 



OPTIONAL, 
OPTIONAL 



disconnect Specific Information 
initiatingEntity 

routeingAreaUpdate 



[3] SEQUENCE { 

[0] InitiatingEntity 

[1] NULL 



OPTIONAL, 
OPTIONAL 



pDPContext Establishment Specific Information 



accessPointName 

endUserAddress 

qualityOf Service 

locationlnformationGPRS 

timeAndTimeZone 

pDPInitiationType 



[4] SEQUENCE { 

[0] AccessPointName {bound} 

[1] EndUserAddress {bound} 

[2] QualityOfService 

[3] LocationlnformationGPRS 

[4] TimeAndTimezone {bound} 

[5] PDPInitiationType 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
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secondaryPDP- context 



[ 6 ] NULL 



OPTIONAL 



pDPContext Establishment Acknowledgement Specific Information 



accessPointName 

chargingID 

endUserAddress 

qualityOf Service 

locationlnformationGPRS 

timeAndTimeZone 

gGSNAddress 



[5] SEQUENCE { 

[0] AccessPointName {bound} 

[1] GPRSChargingID 

[2] EndUserAddress {bound} 

[3] QualityOfService 

[4] LocationlnformationGPRS 

[5] TimeAndTimezone {bound} 

[6] GSN-Address 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 

OPTIONAL 



GPRSEventType : : = ENUMERATED { 

attach (1) , 

attachChangeOf Position (2) , 

detached (3) , 

pdp-ContextEstablishment (11) 
pdp- Context Establishment Acknowledgement 

disonnect (13) 

pdp-ContextChangeOf Position (14) 



(12) 



Inbandlnfo { PARAMETERS - BOUND 
messagelD 

numberOf Repetitions 
duration 
interval 



bound} ::= SEQUENCE { 

[0] MessagelD {bound}, 
[1] INTEGER (1. .127) 
[2] INTEGER (0 . .32767) 
[3] INTEGER (0 . .32767) 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



-- Interval is the time in seconds between each repeated announcement. Duration is the total 

-- amount of time in seconds, including repetitions and intervals. 

-- The end of announcement is either the end of duration or numberOf Repetitions, 

-- whatever comes first. 

-- duration with value indicates infinite duration 

InformationToSend { PARAMETERS - BOUND : bound} ::= CHOICE { 

inbandlnfo [0] Inbandlnfo {bound}, 

tone [1] Tone 



InitiatingEntity 



ENUMERATED 



mobiles tat ion 




(0) 


sgsn 




(1) 


hlr 




(2) 


ggsn 
} 




(3) 


InitiatorOf ServiceChange : : 


: = ENUMERATED 


{ 


a-side 


(0) , 




b-side 


(1) 





Invoke ID 



INTEGER (-128 . .127) 



IPRoutingAddress { PARAMETERS - BOUND : bound} : 
-- Indicates the routeing address for the IP. 



CalledPartyNumber {bound} 



IPSSPCapabilities { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminlPSSPCapabilitiesLength . . bound. kmaxIPSSPCapabilitiesLength) ) 

Indicates the gsmSRF resources available. The parameter has two parts, a standard and a 

bilateral part. The standard part indicates capabilities defined as optional in CAP 

that shall be recognised (but not necessarily supported) by a gsmSCF. The bilateral 

part contains further information that is not specified in this standard, but which is set 

according to bilateral agreements between network operators and/or equipment vendors. 

The last octet of the standard part is indicated by bit 7 being set to 0, otherwise Bit 7 of 

a standard part octet is set to 1 indicating that the standard part continues in the following 

octet. Coding is as follows: 



Octet 1 
Bit Value 


1 

1 
1 



Standard Part for CAP 

Meaning 

IPRoutingAddress not supported 

IPRoutingAddress supported 

VoiceBack not supported 

VoiceBack supported 
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Voicelnformation not supported, via speech recognition 

Voicelnformation supported, via speech recognition 

Voicelnformation not supported, via voice recognition 

Voicelnformation supported, via voice recognition 

Generation of voice announcements from Text not supported 

Generation of voice announcements from Text supported 

Reserved 

Reserved 

End of standard part 

This value is reserved in CAP 



Octets 2 to 4 



Bilateral Part: Network operator/equipment vendor specific 



LegOrCallSegment { PARAMETERS - BOUND : bound} ::= CHOICE { 

callSegmentID [0] CallSegmentID {bound}, 

legID [1] LegID 



LegType :: = OCTET STRING (SIZE(l)) 
legl LegType ::= '01'H 
leg2 LegType ::= '02'H 



LocationlnformationGPRS 



SEQUENCE 



cellGloballdOrServiceArealdOrLAI [0] 

routeingArealdentity [1] 

geographicallnformation [2] 

sgsn-Number [3] 

selectedLSAIdentity [4] 

extensionContainer [5] 



OCTET STRING (SIZE (5.. 7)) 

RAIdentity 

Geographicallnformation 

ISDN-AddressString 

LSAIdentity 

ExtensionContainer 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



sai-Present 
userCSGInformation 



[ 6 ] NULL 

[7] UserCSGInformation 



OPTIONAL, 
OPTIONAL 



-- cellGloballdOrServiceArealdOrLAI shall contain the value part of the 

-- CellGloballdOrServiceArealdFixedLength type or the LAIFixedLength type (i.e. excluding tags 

-- and lengths) as defined in 3GPP TS 29.002 [13] . 

-- sai-Present indicates that the cellGloballdOrServiceArealdOrLAI parameter contains 

-- a Service Area Identity. 

-- UserCSGInformation contains the CSG ID as defined in 3GPP TS 23.003 [5] . 

LocationNumber { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE ( 

bound. SminLocationNumberLength . . bound. SmaxLocationNumberLength) ) 
-- Indicates the Location Number for the calling party. 
-- Refer to ETSI EN 300 356-1 [23] for encoding. 

LowLayerCompatibility { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE ( 

bound. kminLowLayerCompatibilityLength . . bound. SmaxLowLayerCompatibilityLength) ) 
-- indicates the LowLayerCompatibility for the calling party. 
-- Refer to 3GPP TS 24.008 [9] for encoding. 

-- It shall be coded as in the value part defined in 3GPP TS 24.008. 
-- i.e. the 3GPP TS 24.008 IEI and 3GPP TS 24.008 octet length indicator 
-- shall not be included. 



MessagelD { PARAMETERS - BOUND : bound} ::= CHOICE { 
elementaryMessagelD [0] 

text [1] 

messageContent 

bound . SminMessageContentLength 
attributes 



Integer4 , 
SEQUENCE { 
[0] IA5String (SIZE( 
. . bound. kmaxMessageContentLength) ) 
[1] OCTET STRING (SIZE( 



bound. kminAttributesLength .. bound. kmaxAttributesLength) ) 



OPTIONAL 



element aryMes sage IDs 
variableMessage 

elementaryMessagelD 

variableParts 



[29] SEQUENCE SIZE (1.. bound . knumOf MessagelDs ) OF Integer4 , 
[3 0] SEQUENCE { 

[0] Integer4, 

[1] SEQUENCE SIZE (1..5) OF VariablePart {bound} 



-- Use of the text parameter is network operator/equipment vendor specific. 

MetDPCriteriaList { PARAMETERS - BOUND : bound} ::= SEQUENCE SIZE 
(1 . .bound. knumOfChangeOfPositionControlInfo) OF MetDPCriterion {bound} 



MetDPCriterion { PARAMETERS - BOUND 
enteringCellGloballd 
leavingCellGloballd 
enter ingServiceAreald 
leavingServiceAreald 
enter ingLocationAreald 



bound} : := CHOICE { 

[0] CellGloballdOrServiceArealdFixedLength, 
[1] CellGloballdOrServiceArealdFixedLength, 
[2] CellGloballdOrServiceArealdFixedLength, 
[3] CellGloballdOrServiceArealdFixedLength, 
[4] LAIFixedLength, 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 



43 



ETSI TS 129 078 V8.2.1 (2010-04) 



leavingLocationAreald 
inter- SystemHandOverToUMTS 
inter- SystemHandOverToGSM 
inter- PLMNHandOver 
inter-MSCHandOver 
metDPCriterionAlt 



[5] LAIFixedLength, 

[ 6 ] NULL , 

[7] NULL, 

[ 8 ] NULL , 

[9] NULL, 

[10] MetDPCriterionAlt {bound} 



The enteringCellGloballd and leavingCellGloballd shall contain a Cell Global Identification. 
The enteringServiceAreald and leavingServiceAreald shall contain a Service Area Identification. 



MetDPCriterionAlt { PARAMETERS - BOUND : bound} 



SEQUENCE { 



MidCallControlInfo ::= SEQUENCE 
minimumNumberOf Digits 
maximumNumberOf Digits 
endOfReplyDigit 
cancelDigit 
startDigit 
interDigitTimeout 



[0] INTEGER (1..30) DEFAULT 1, 

[1] INTEGER (1..30) DEFAULT 30, 

[2] OCTET STRING (SIZE (1..2)) 

[3] OCTET STRING (SIZE (1..2)) 

[4] OCTET STRING (SIZE (1..2)) 

[6] INTEGER (1..127) DEFAULT 10, 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



minimumNumberOf Digits 
maximumNumberOf Digits 
endOfReplyDigit 

cancelDigit 

startDigit 

interDigitTimeout 



specifies the minumum number of digits that shall be collected 

specifies the maximum number of digits that shall be collected 

specifies the digit string that denotes the end of the digits 

to be collected. 

specifies the digit string that indicates that the input shall 

be erased and digit collection shall start afresh. 

specifies the digit string that denotes the start of the digits 

to be collected. 

specifies the maximum duration in seconds between successive 

digits . 



endOfReplyDigit, cancelDigit and startDigit shall contain digits in the range 0..9, '*' and '#' 
only. The collected digits string, reported to the gsmSCF, shall include the endOfReplyDigit and 
the startDigit, if present. 

endOfReplyDigit, cancelDigit and startDigit shall be encoded as BCD digits. Each octet shall 

contain one BCD digit, in the 4 least significant bits of each octet. 

The following encoding shall be used for the over-decadic digits: 1011 (*) , 1100 {#) . 



MonitorMode ; : = ENUMERATED 
interrupted 
not i f yAndCont inue 
transparent 



(0) 
(1) 
(2) 



Indicates the event is relayed and/or processed by the SSP. 

Transparent means that the gsmSSF or gprsSSF does not notify the gsmSCF of the event. 

For the use of this parameter refer to the procedure descriptions in clause 11. 

For the RequestNotif icationCharging operation, 'interrupted' shall not be used in MonitorMode. 



MO-SMSCause ::= ENUMERATED { 
systemFailure 
unexpectedDataValue 
facilityNot Supported 
sM- Del iveryFai lure 
releaseFromRadioInterf ace 



(0) 
(1) 
(2) 
(3) 
(4) 



-- MO SMS error values which are reported to gsmSCF. 

-- Most of these values are received from the SMSC as a response to 

-- MO-ForwardSM operation. 

MT-SMSCause :: = OCTET STRING (SIZE (1)) 

-- This variable is sent to the gsmSCF for a Short Message delivery failure 

-- notification. 

--If the delivery failure is due to RP-ERROR RPDU received from the MS, 

-- then MT-SMSCause shall be set to the RP-Cause component in the RP-ERROR RPDU. 

-- Refer to 3GPP TS 24.011 [10] for the encoding of RP-Cause values. 

-- Otherwise, if the delivery failure is due to internal failure in the MSC or SGSN 

-- or time-out from the MS, then MT-SMSCause shall be set to 'Protocol error, 

-- unspecified', as defined in 3GPP TS 24.011 [10]. 

NAOlilnfo ::= OCTET STRING (SIZE (1)) 

-- NA Oli information takes the same value as defined in ANSI Tl. 113-1995 [92] 

e.g. '3D'H - Decimal value 61 - Cellular Service (Type 1) 

'3E'H - Decimal value 62 - Cellular Service (Type 2) 
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1 3F'H 



Decimal value 63 - Cellular Service (roaming) 



NatureOf ServiceChange ; : = ENUMERATED { 

userlnitiated (0), 

networklnitiated (1) 



NumberOfDigits ::= INTEGER (1..255) 

Indicates the number of digits to be collected. 

OCSIApplicable ::= NULL 

Indicates that the Originating CAMEL Subscription Information, if present, shall be 
applied on the outgoing call leg created with a Connect operation. For the use of this 

-- parameter see 3GPP TS 23.078 [7] . 

OriginalCalledPartylD { PARAMETERS - BOUND ; bound} ; := OCTET STRING <SIZE< 

bound. kminOriginalCalledPartylDLength . . bound. SmaxOriginalCalledPartylDLength) ) 

Indicates the original called number. Refer to ETSI EN 300 356-1 [23] Original Called Number 

for encoding. 

PDPID ::= OCTET STRING (SIZE (1)) 

PDP Identifier is a counter used to identify a specific PDP Context within a control 
relationship between gprsSSF and gsmSCF. 

PDPInitiationType ::= ENUMERATED { 
mSInitiated 
networklnitiated 



QualityOf Service : ; 
requested-QoS 
subscribed- QoS 
negotiated-QoS 



requested- QoS -Ext ens ion 
subscribed- QoS -Ext ens ion 
negotiated- QoS -Ext ens ion 





(0) 






(1) 




SEQUENCE { 








[0] 


GPRS -QoS 




[1] 


GPRS -QoS 




[2] 


GPRS-QoS 



[3] GPRS-QoS-Extension 
[4] GPRS-QoS-Extension 
[5] GPRS-QoS-Extension 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 

OPTIONAL, 
OPTIONAL, 
OPTIONAL 



ReceivingSidelD ;:= CHOICE { 

receivingSidelD [1] LegType 

} 

-- used to identify LegID in operations sent from gsmSSF to gsmSCF 

RedirectingPartylD { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE ( 

bound. kminRedirectingPartylDLength . . bound. SmaxRedirectingPartylDLength) ) 
-- Indicates redirecting number. 
-- Refer to ETSI EN 300 356-1 [23] Redirecting number for encoding. 

RequestedlnformationList { PARAMETERS - BOUND : bound} ::= SEQUENCE SIZE (1.. numOf Inf oltems) OF 
Requestedlnformation {bound} 

RequestedlnformationTypeList ::= SEQUENCE SIZE (1.. numOf Inf oltems) OF Requestedlnf ormationType 

Requestedlnformation { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

requestedlnformationType [0] Requestedlnf ormationType, 

requestedlnformationValue [1] RequestedlnformationValue {bound}, 



RequestedlnformationType ::= ENUMERATED { 

callAttemptElapsedTime (0) , 

callStopTime (1) , 

callConnectedElapsedTime (2), 

releaseCause (30) 



RequestedlnformationValue { PARAMETERS - BOUND : bound} ::= CHOICE { 
callAttemptElapsedTimeValue [0] INTEGER (0..255), 

callStopTimeValue [1] DateAndTime, 

callConnectedElapsedTime Value [2] Integer4, 
releaseCauseValue [30] Cause {bound} 

} 
-- The callAttemptElapsedTimeValue is specified in seconds. The unit for the 
-- callConnectedElapsedTime Value is 100 milliseconds 

RPCause ::= OCTET STRING (SIZE (1)) 

-- RP cause according to 3GPP TS 24.011 [10] or 3GPP TS 29.002 [11] . 
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GsmSCF shall send this cause in the ReleaseSMS operation. 

For a MO-SMS service, the MSC or SGSN shall send the RP Cause to the originating MS. 

It shall be used to overwrite the RP-Cause element in the RP-ERROR RPDU. 

For a MT-SMS service, the MSC or SGSN shall send the RP Cause to the sending SMS-GMSC. 

It shall be used to overwrite the RP-Cause element in the RP-ERROR RPDU. 



ScfID {PARAMETERS -BOUND : bound} ::= OCTET STRING (SIZE( 

bound. kminScf IDLength .. bound. kmaxScf IDLength) ) 
-- defined by network operator. 
-- Indicates the gsmSCF identity. 

SCIBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE { 
bound. kminSCIBillingChargingLength . . bound. kmaxSCIBillingChargingLength) ) 
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type -- 
CAMEL-SCIBillingChargingCharacteristics} ) 

-- Indicates AOC information to be sent to a Mobile Station 

-- The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 

SCIGPRSBillingChargingCharacteristics { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE { 
bound. kminSCIBillingChargingLength . . bound. kmaxSCIBillingChargingLength) ) 
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type - 
CAMEL-SCIGPRSBillingChargingCharacteristics}) 

-- Indicates AOC information to be sent to a Mobile Station 

-- The violation of the UserDef inedConstraint shall be handled as an ASN.l syntax error. 

SendingSidelD ::= CHOICE {sendingSidelD [0] LegType} 

-- used to identify LegID in operations sent from gsmSCF to gsmSSF 



ServicelnteractionlndicatorsTwo ::= SEQUENCE { 

forwardServicelnteractionlnd [0] ForwardServicelnteractionlnd 

-- applicable to operations InitialDP, Connect and ContinueWithArgument . 

backwardServicelnteractionlnd [1] BackwardServicelnteractionlnd 

-- applicable to operations Connect and ContinueWithArgument. 

bothwayThroughConnectionlnd [2] BothwayThroughConnectionlnd 

-- applicable to ConnectToResource and EstablishTemporaryConnection 

connectedNumberTreatmentlnd [4] ConnectedNumberTreatmentlnd 

-- applicable to Connect and ContinueWithArgument 

nonCUGCall [13] NULL 

-- applicable to Connect and ContinueWithArgument 

-- indicates that no parameters for CUG shall be used for the call (i.e. 

-- be a non-CUG call) . 

-- If not present, it indicates one of three things: 

a) continue with modified CUG information (when one or more of either 
and Outgoing Access Indicator are present) , or 

b) continue with original CUG information (when neither CUG Interlock 
Access Indicator are present) , i.e. no IN impact. 

c) continue with the original non-CUG call. 
holdTreatmentlndicator [50] OCTET STRING (SIZE(l)) 
-- applicable to InitialDP, Connect and ContinueWithArgument 

-- acceptHoldRequest 'xxxx xxOl'B 

-- rejectHoldRequest 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument, 

-- then CAMEL service does not affect call hold treatment 

cwTreatmentlndicator [51] OCTET STRING (SIZE(l)) 

-- applicable to InitialDP, Connect and ContinueWithArgument 

-- acceptCw 'xxxx xxOl'B 

-- rejectCw 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument, 

-- then CAMEL service does not affect call waiting treatment 

ectTreatmentlndicator [52] OCTET STRING (SIZE(l)) 

-- applicable to InitialDP, Connect and ContinueWithArgument 

-- acceptEctRequest 'xxxx xxOl'B 

-- rejectEctRequest 'xxxx xxlO'B 

-- if absent from Connect or ContinueWithArgument, 

-- then CAMEL service does not affect explicit call transfer treatment 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
the call shall 

CUG Interlock Code 
Code or Outgoing 

OPTIONAL, 



OPTIONAL, 



OPTIONAL, 



SGSNCapabilities 



OCTET STRING (SIZE (1) ) 



Indicates the SGSN capabilities. The coding of the parameter is as follows: 

Bit Value Meaning 

AoC not supported by SGSN 
1 AoC supported by SGSN 

1 - This bit is reserved in CAP V.3 

2 - This bit is reserved in CAP V.3 

3 - This bit is reserved in CAP V.3 

4 - This bit is reserved in CAP V.3 
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--5 - This bit is reserved in CAP V.3 

--6 - This bit is reserved in CAP V.3 

--7 - This bit is reserved in CAP V.3 

SMS-AddressString ::= AddressString (SIZE (1 .. maxSMS-AddressStringLength) ) 

-- This data type is used to transport CallingPartyNumber for MT-SMS. 

-- If this data type is used for MO-SMS, then the maximum number of digits shall be 16. 

-- An SMS-AddressString may contain an alphanumeric character string. In this 

-- case, a nature of address indicator 'lOl'B is used, in accordance with 

-- 3GPP TS 23.040 [6] . The address is coded in accordance with the GSM 7-bit 

-- default alphabet definition and the SMS packing rules as specified in 

-- 3GPP TS 23.038 [15] in this case. 

maxSMS-AddressStringLength INTEGER ::= 11 

SMSEvent : : = SEQUENCE { 

eventTypeSMS [0] EventTypeSMS , 

monitorMode [1] MonitorMode 

} 

TariffSwitchlnterval ::= INTEGER (1 .. 86400) 

-- TariffSwitchlnterval is measured in 1 second units 

TimeAndTimezone { PARAMETERS - BOUND : bound} ::= OCTET STRING (SIZE( 

bound. StminTimeAndTimezoneLength . . bound. kmaxTimeAndTimezoneLength) ) 

Indicates the time and timezone, relative to GMT. This parameter is BCD encoded. 

The year digit indicating millenium occupies bits 0-3 of the first octet, and the year 

digit indicating century occupies bits 4-7 of the first octet. 

The year digit indicating decade occupies bits 0-3 of the second octet, whilst the digit 

indicating the year within the decade occupies bits 4-7 of the second octet. 

The most significant month digit occupies bits 0-3 of the third octet, and the least 

significant month digit occupies bits 4-7 of the third octet. 

The most significant day digit occupies bits 0-3 of the fourth octet, and the least 

significant day digit occupies bits 4-7 of the fourth octet. 

The most significant hours digit occupies bits 0-3 of the fifth octet, and the least 

significant hours digit occupies bits 4-7 of the fifth octet. 

The most significant minutes digit occupies bits 0-3 of the sixth octet, and the least 

significant minutes digit occupies bits 4-7 of the sixth octet. 

The most significant seconds digit occupies bits 0-3 of the seventh octet, and the least 

significant seconds digit occupies bits 4-7 of the seventh octet. 

The timezone information occupies the eighth octet. For the encoding of Timezone refer to 
-- 3GPP TS 23.040 [6] . 

The BCD digits are packed and encoded as follows: 

-- Bit 765 4|3210 

2nd digit j 1st digit Octet 1 

3rd digit j 4th digit Octet 2 



nth digit 


1 n- 


■1 


0000 


digit 





0001 


digit 


1 


0010 


digit 


2 


0011 


digit 


3 


0100 


digit 


4 


0101 


digit 


5 


0110 


digit 


6 


0111 


digit 


7 


1000 


digit 


8 


1001 


digit 


9 


1010 


spare 




1011 


spare 




1100 


spare 




1101 


spare 




1110 


spare 




1101 


spare 





Octet m 



-- where the leftmost bit of the digit is either bit 7 or bit 3 of the octet. 

TimelfNoTariffSwitch ::= INTEGER (0 .. 864000) 

-- TimelfNoTariffSwitch is measured in 100 millisecond intervals 

TimelfTariff Switch :: = SEQUENCE { 

timeSinceTariffSwitch [0] INTEGER (0 .. 864000) , 

tariffSwitchlnterval [1] INTEGER (1 .. 864000) OPTIONAL 
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-- timeSinceTariff Switch and tariff Switchlnterval are measured in 100 millisecond intervals 

Timelnformation ::= CHOICE { 

timelfNoTarif fSwitch [0] TimelfNoTarif f Switch, 

timelfTarif fSwitch [1] TimelfTariff Switch 

} 

-- Indicates call duration information 

TimerlD ; ; = ENUMERATED { 

tssf (0) 

} 
-- Indicates the timer to be reset. 

TimerValue ; ; = Integer4 

-- Indicates the timer value (in seconds) . 

Tone : : = SEQUENCE { 

tonelD [0] Integer4, 

duration [1] Integer4 OPTIONAL, 

} 
-- The duration specifies the length of the tone in seconds, value indicates infinite duration. 

TPDataCodingScheme :: = OCTET STRING (SIZE (1)) 

-- TP Data Coding Scheme according to 3GPP TS 23.040 [6] 

TPProtocolIdentifier ::= OCTET STRING (SIZE (1)) 

-- indicates the protocol used above the SM-Transfer Layer as specified in 3GPP TS 23.040 [6] . 

TPShortMessageSpecificInfo ::= OCTET STRING (SIZE (1)) 

-- contains the l Bt octect of the applicable TPDU or the SMS - COMMAND TPDU as specified in 

-- 3GPP TS 23.040 [6] . 

TPValidityPeriod ::= OCTET STRING (SIZE (1..7)) 

-- indicates the length of the validity period or the absolute time of the validity 

-- period termination as specified in 3GPP TS 23.040 [6] . 

-- the length of ValidityPeriod is either 1 octet or 7 octets 

TransferredVolume ::= CHOICE { 

volumelfNoTariffSwitch [0] INTEGER ( .. 4294967295 ) , 

volumelfTariffSwitch [1] SEQUENCE { 

volumeSinceLastTariffSwitch [0] INTEGER ( .. 4294967295 ) , 

volumeTariffSwitchlnterval [1] INTEGER (0 .. 4294967295) OPTIONAL 

} 

} 

volumelfNoTariffSwitch, volumeSinceLastTariffSwitch and volumeTariffSwitchlnterval 

are measured in bytes. 

TransferredVolumeRollOver ::= CHOICE { 

rO-VolumelfNoTariffSwitch [0] INTEGER (0..255), 

rO-VolumelfTariffSwitch [1] SEQUENCE { 

rO-VolumeSinceLastTariffSwitch [0] INTEGER (0..255) OPTIONAL, 

rO-VolumeTariffSwitchlnterval [1] INTEGER (0..255) OPTIONAL 

} 

} 

rO-VolumelfNoTarif fSwitch, rO-VolumeSinceLastTarif fSwitch and rO-VolumeTariff Switchlnterval 

present counters indicating the number of parameter range rollovers. 

UnavailableNetworkResource : := ENUMERATED { 
unavailableResources (0), 

componentFailure (1) , 

basicCallProcessingException (2) , 
resourceStatusFailure (3), 

endUserFailure (4) 

} 

-- Indicates the network resource that failed. 

VariablePart { PARAMETERS - BOUND ; bound} ::= CHOICE { 

integer [0] Integer4, 

number [1] Digits {bound}, -- Generic digits 

time [2] OCTET STRING (SIZE(2)), -- HH : MM, BCD coded 

date [3] OCTET STRING (SIZE(4)), -- YYYYMMDD, BCD coded 

price [4] OCTET STRING (SIZE(4)) 

} 

Indicates the variable part of the message. Time is BCD encoded. 

The most significant hours digit occupies bits 0-3 of the first octet, and the least 
significant digit occupies bits 4-7 of the first octet. The most significant minutes digit 
occupies bits 0-3 of the second octet, and the least significant digit occupies bits 4-7 
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of the second octet. 

Date is BCD encoded. The year digit indicating millenium occupies bits 0-3 of the first octet, 
and the year digit indicating century occupies bits 4-7 of the first octet. The year digit 
indicating decade occupies bits 0-3 of the second octet, whilst the digit indicating the year 
within the decade occupies bits 4-7 of the second octet. 

The most significant month digit occupies bits 0-3 of the third octet, and the least 
significant month digit occupies bits 4-7 of the third octet. The most significant day digit 
occupies bits 0-3 of the fourth octet, and the least significant day digit occupies bits 4-7 
of the fourth octet. 

Price is BCD encoded. The digit indicating hundreds of thousands occupies bits 0-3 of the 
first octet, and the digit indicating tens of thousands occupies bits 4-7 of the first octet. 
The digit indicating thousands occupies bits 0-3 of the second octet, whilst the digit 
indicating hundreds occupies bits 4-7 of the second octet. The digit indicating tens occupies 
bits 0-3 of the third octet, and the digit indicating to 9 occupies bits 4-7 of the third 
octet. The tenths digit occupies bits 0-3 of the fourth octet, and the hundredths digit 
occupies bits 4-7 of the fourth octet. 

For the encoding of digits in an octet, refer to the timeAndtimezone parameter 

-- The Definition of range of constants follows 
numOflnfoItems INTEGER ::= 4 



5.2 Error types 



CAP-errortypes {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umts-network (1) 
modules (3) cap-errortypes (51) version5(4)} 

-- This module contains the type definitions for the CAP Error Types. 

-- Where a parameter of type CHOICE is tagged with a specific tag value, the tag is automatically 

-- replaced with an EXPLICIT tag of the same value. 

DEFINITIONS IMPLICIT TAGS ::= BEGIN 

IMPORTS 

ros- Inf ormationOb j ects , 

datatypes, 

errorcodes 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umts-network (1) modules (3) cap-object-identifiers (100) version5(4)} 

ERROR 
FROM Remote -Operations -Information- Objects ros- Inf ormationOb j ects 

InvokelD, 

UnavailableNetworkResource 
FROM CAP-datatypes datatypes 

errcode- canceled, 
errcode-cancelFailed, 
errcode -eTCFai led, 
errcode- improperCallerResponse, 
errcode -mi ssingCustomerRecord, 
errcode -mi ssingParameter, 
errcode-parameterOutOf Range , 
errcode -requestedlnfoError, 
errcode- systemFailure, 
errcode -taskRe fused, 
errcode -unavailableResource, 
errcode -unexpectedComponent Sequence, 
errcode-unexpectedDataValue , 
errcode -unexpectedParameter, 
errcode - unknownLegID , 
errcode -unknownCS ID, 
errcode -unknownPDPID 
FROM CAP-errorcodes errorcodes 



-- TYPE DEFINITION FOR CAP ERROR TYPES FOLLOWS 

canceled ERROR ; ; = { 

CODE errcode-canceled 
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-- The operation has been canceled. 

cancelFailed ERROR ::= { 

PARAMETER SEQUENCE { 

problem [0] ENUMERATED { 

unknownOperation (0), 

tooLate (1) , 

operationNotCancellable (2) 

}, 

operation [1] InvokelD, 

}" 
CODE errcode-cancelFailed 

} 

-- The operation failed to be canceled. 

eTCFailed ERROR ::= { 

CODE errcode-eTCFailed 

} 
-- The establish temporary connection failed. 

improperCallerResponse ERROR ::= { 

CODE errcode- improperCallerResponse 

} 
-- The caller response was not as expected. 

missingCustomerRecord ERROR ::= { 

CODE errcode -missingCustomerRecord 

} 
-- The Service Logic Program could not be found in the gsmSCF. 

missingParameter ERROR : := { 

CODE errcode-missingParameter 

} 
-- An expected optional parameter was not received. 

parameterOutOf Range ERROR ; : = { 

CODE errcode-parameterOutOfRange 

} 
-- The parameter was not as expected (e.g. missing or out of range) . 

requestedlnf oError ERROR ::= { 
PARAMETER ENUMERATED { 

unknownRequestedlnf o (1) , 
requestedlnf oNotAvailable (2) 

} 

CODE errcode-requestedlnfoError 

} 
-- The requested information cannot be found. 

systemFailure ERROR ::= { 

PARAMETER UnavailableNetworkResource 
CODE errcode- systemFailure 

} 
-- The operation could not be completed due to a system failure at the serving physical entity. 

taskRef used ERROR ; : = { 

PARAMETER ENUMERATED { 

generic (0) , 

unobtainable (1) , 

congestion (2) 

} 
CODE errcode-taskRefused 

} 

-- An entity normally capable of the task requested cannot or chooses not to perform the task at 
-- this time. This includes error situations like congestion and unobtainable address as used in 
-- e.g. the connect operation.) 

unavailableResource ERROR ::= { 

CODE errcode-unavailableResource 

} 
-- A requested resource is not available at the serving entity. 

unexpectedComponentSequence ERROR ; : = { 

CODE errcode -unexpectedComponentSequence 

} 
-- An incorrect sequence of Components was received (e.g. ' DisconnectForwardConnection' 
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-- followed by ' PlayAnnouncement ' ) . 

unexpectedDataValue ERROR ; : = { 

CODE errcode-unexpectedDataValue 

} 
-- The data value was not as expected (e.g. route number expected but billing number received) 

unexpectedParameter ERROR : : = { 

CODE errcode-unexpectedParameter 

} 
-- A parameter received was not expected. 

unknownLegID ERROR : : = { 

CODE errcode-unknownLegID 

} 
-- Leg not known to the gsmSSF. 

unknownCSID ERROR ::= { 

CODE errcode-unknownCSID 

} 
-- Call Segment not known to the gsmSSF. 

unknownPDPID ERROR : : = { 

CODE errcode-unknownPDPID 

} 

-- PDPID not known by the receiving entity. 

END 

5.3 Operation codes 

CAP-operationcodes {itu-t{0) identif ied-organization (4) etsi(0) mobileDomain (0) umts- network (1) 
modules{3) cap-operationcodes (53) version5(4)} 

DEFINITIONS ::= BEGIN 

IMPORTS 

ros-InformationObjects 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

Code 
FROM Remote -Operations -Information- Objects ros-InformationObjects 



the operations are grouped by the identified operation packages. 

gsmSCF activation Package 

opcode-initialDP Code ::= local: 

gsmSCF/gsmSRF activation of assist Package 

opcode-assistRequestlnstructions Code ::= local: 16 

Assist connection establishment Package 

opcode-establishTemporaryConnection Code ::= local: 17 
Generic disconnect resource Package 

opcode-disconnectForwardConnection Code ::= local: 18 

opcode-dFCWithArgument Code ::= local: 86 

Non-assisted connection establishment Package 

opcode-connectToResource Code ::= local: 19 

Connect Package (elementary gsmSSF function) 

opcode -connect Code ::= local: 20 

Call handling Package (elementary gsmSSF function) 

opcode-releaseCall Code ::= local: 22 

BCSM Event handling Package 

opcode-requestReportBCSMEvent Code ::= local: 23 

opcode-eventReportBCSM Code ::= local: 24 

gsmSSF call processing Package 

opcode-collectlnformation Code ::= local: 27 

opcode-continue Code ::= local: 31 

gsmSCF call initiation Package 

opcode-initiateCallAttempt Code ::= local: 32 

Timer Package 

opcode-resetTimer Code ::= local: 33 

Billing Package 
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opcode -furnishCharginglnformat ion 
Charging Package 

opcode -applyCharging 

opcode - applyChargingReport 
Traffic management Package 

opcode -callGap 
Call report Package 

opcode -calllnformationReport 

opcode -calllnformationReque st 
Signalling control Package 

opcode -sendCharginglnf ormat ion 
Specialized resource control Package 

opcode -playAnnouncement 

opcode -prompt AndCol lee tUser Information 

opcode- spec ializedResourceReport 
Cancel Package 

opcode -cancel 
Activity Test Package 

opcode- act ivityTe st 
CPH Response Package 

opcode - cont inueWithArgument 

opcode - disconnecting 

opcode -moveLeg 

opcode- splitLeg 
Exception Inform Package 

opcode -entityRe leased 
Play Tone Package 

opcode -playTone 

Sms Activation Package 

opcode- initialDPSMS 
Sms Billing Package 

opcode -furnishCharginglnf ormat ionSMS 
Sms Connect Package 

opcode -connect SMS 
Sms Event Handling Package 

opcode - requestReportSMSEvent 

opcode -eventReport SMS 
Sms Processing Package 

opcode - cont inueSMS 
Sms Release Package 

opcode- re leaseSMS 
Sms Timer Package 

opcode -resetTimerSMS 



Code 



Code 
Code 



Code 



Code 
Code 



Code 



local: 34 



local : 
local : 



local : 
local : 



35 
36 



local: 41 



44 
45 



local: 46 



Code : 


: = local 


47 


Code : 


: = local 


48 


Code : 


: = local 


49 


Code : 


: = local 
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Code : 


: = local 


55 


Code : 


: = local 


88 


Code : 


: = local 


90 


Code : 


: = local 


93 


Code : 


: = local 


95 


Code : 


: = local 


96 


Code : 


: = local 


97 


Code : 


: = local 


60 


Code : 


: = local 


61 


Code : 


: = local 


62 


Code : 


: = local 


63 


Code : 


: = local 


64 


Code : 


: = local 


65 


Code : 


: = local 


66 


Code : 


: = local 


67 



Gprs Activity Test Package 

opcode -activi tyTes tGPRS 
Gprs Charging Package 

opcode - applyChargingGPRS 

opcode - applyChargingReportGPRS 
Gprs Cancel Package 

opcode -cancelGPRS 
Gprs Connect Package 

opcode -connec tGPRS 
Gprs Processing Package 

opcode- cont inueGPRS 
Gprs Exception Information Package 

opcode -entityReleasedGPRS 
Gprs Billing Package 

opcode -furnishCharginglnf ormat ionGPRS 
Gprs Scf Activation Package 

opcode -initialDPGPRS 
Gprs Release Package 

opcode -releaseGPRS 
Gprs Event Handling Package 

opcode - eventReportGPRS 

opcode - requestReportGPRSEvent 
Gprs Timer Package 

opcode -resetTimerGPRS 
Gprs Charge Advice Package 

opcode -sendCharginglnf ormat ionGPRS 



Code 



local: 70 



Code 


: = local : 


71 


Code 


: = local : 


72 


Code 


: = local : 


73 


Code 


: = local : 


74 


Code 


: = local : 


75 


Code 


: = local : 


76 


Code 


: = local : 


77 


Code 


: = local : 


78 


Code 


: = local : 


79 


Code 


: = local : 


80 


Code 


: = local : 


81 


Code 


: = local : 


82 


Code 


: = local : 


83 
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5.4 



Error codes 



CAP-errorcodes {itu-t{0) identif ied-organization (4) etsi(0) mobileDomain (0) umts- network (1) 
modules (3) cap-errorcodes (57) version5(4)} 

DEFINITIONS ::= BEGIN 

IMPORTS 

ros-InformationObjects 
FROM CAP-object-identif iers {itu-t{0) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

Code 
FROM Remote -Operations -Information- Objects ros-InformationObjects 



errcode- canceled 

errcode-cancelFailed 

errcode -eTCFai led 

errcode- improperCallerResponse 

errcode -mi ssingCustomerRecord 

errcode -mi ssingParameter 

errcode -parameterOutOf Range 

errcode -requestedlnfoError 

errcode- systemFailure 

errcode -taskRef used 

errcode -unavailableResource 

errcode -unexpectedComponent Sequence 

errcode -unexpectedDataValue 

errcode -unexpectedParameter 

errcode -unknownLegID 

errcode -unknownPDPID 

errcode - unknownCS ID 



Code : 


= local 





Code : 


= local 


1 


Code : 


= local 


3 


Code : 


= local 


4 


Code : 


= local 
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Code : 


= local 


7 


Code : 


= local 


8 


Code : 


= local 


10 


Code : 


= local 


11 


Code : 


= local 


12 


Code : 


= local 


13 


Code : 


= local 


14 


Code : 


= local 


15 


Code : 


= local 


16 


Code : 


= local 


17 


Code : 


= local 


50 


Code : 


= local 


51 



END 



5.5 Classes 



CAP-classes {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) 
modules (3) cap-classes (54) version5(4)} 

DEFINITIONS ::= BEGIN 

IMPORTS 

ROS -OB JECT- CLASS , 
Code 
FROM Remote -Operations -Information- Objects ros-InformationObjects 

id-rosObject-gprsSSF, 

id-rosObject-gsmSRF, 

id-rosObject-gsmSSF, 

id-rosObject-smsSSF-V3, 

id-rosObject-smsSSF-V4, 

ros- Inf ormationOb j ects , 

gsmSSF-gsmSCF-Protocol, 

gsmSCF-gsmSRF- Protocol, 

smsSSF-gsmSCF-Protocol, 

gprsSSF-gsmSCF- Protocol 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

capS sfToScf Generic, 
capAssistHandof f ssf ToScf , 
capScfToSsf Generic 
FROM CAP-gsmSSF-gsmSCF-pkgs- contract s-acs gsmSSF-gsmSCF- Protocol 

gsmSRF-gsmSCF- contract 
FROM CAP-gsmSCF-gsmSRF-pkgs- contract s-acs gsmSCF-gsmSRF- Protocol 

cap3SMS, 
cap4SMS 
FROM CAP- smsSSF-gsmSCF-pkgs- contract s-acs smsSSF-gsmSCF- Protocol 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 53 ETSI TS 129 078 V8.2.1 (2010-04) 

capGprsSsf ToScf , 
capGsmScfToGprsSsf 
FROM CAP-gprsSSF-gsmSCF-pkgs-contracts-acs gprsSSF-gsmSCF- Protocol 

CriticalityType 
FROM CS2-datatypes {itu-t(O) identif ied-organization (4) etsi(0) inDomain(l) in-network (1) cs2{20) 
modules(O) in-cs2-datatypes (0) versionl(O)} 



gsmSSF ROS-OBJECT-CLASS ::= { 

INITIATES {capSsfToScf Generic | 

capAssistHandof f ssf ToScf } 

RESPONDS {capScfToSsf Generic} 

ID id-rosObject-gsmSSF} 

-- The Rel-6 ' gsmSSF ' definition uses the Rel-6 capSsf ToScf Generic, capAssistHandof fssfToScf 
-- and capScfToSsf Generic CONTRACT definitions. 

gsmSRF ROS-OBJECT-CLASS ::= { 

INITIATES {gsmSRF-gsmSCF-contract} 

ID id-rosObject-gsmSRF} 

-- The Rel-6 ' gsmSRF ' definition uses the Rel-6 gsmSRF-gsmSCF-contract CONTRACT definition. 

smsSSF-V3 ROS-OBJECT-CLASS ::= { 

INITIATES {cap3SMS} 

ID id-rosObject-smsSSF-V3} 

-- The Rel-6 ' smsSSF-V3 ' definition uses the Rel-6 cap3SMS CONTRACT definition. The smsSSF-V3 
-- ROS-OBJECT-CLASS is used for MO SMS control. 

smsSSF-V4 ROS-OBJECT-CLASS ::= { 

INITIATES {cap4SMS} 

ID id-rosObject-smsSSF-V4} 

-- The Rel-6 ' smsSSF-V4 ' definition uses the Rel-6 cap4SMS CONTRACT definition. The smsSSF-V4 
-- ROS-OBJECT-CLASS is used for MT SMS control. 

gprsSSF ROS-OBJECT-CLASS ::= { 

INITIATES { capGprsSsf ToScf } 

RESPONDS {capGsmScfToGprsSsf} 

ID id-rosObject-gprsSSF} 

-- The Rel-6 ' gprsSSF ' definition uses the Rel-6 capGprsSsfTogsmScf and capGsmScfToGprsSsf 
-- CONTRACT definitions. 

EXTENSION ::= CLASS { 
&ExtensionType, 

kcriticality CriticalityType DEFAULT ignore, 
&id Code} 

WITH SYNTAX { 

EXTENSION-SYNTAX kExtensionType 

CRITICALITY kcriticality 

IDENTIFIED BY &id 

} 
-- Only value Global OBJECT IDENTIFIER is used for &id; 
-- Only the value ignore (0) is used for kcriticality. 

-- Example of addition of an extension named 'Some Network Specific Indicator 1 of type 
-- BOOLEAN, with criticality 'ignore' and identified by global Object Identifier. 

-- Example of definition using the above information object class: 

-- SomeNetworkSpecif iclndicator EXTENSION ::= { 
-- EXTENSION-SYNTAX BOOLEAN 
-- CRITICALITY ignore 

IDENTIFIED BY global : {itu-t(O) identif ied-organization (4 ) organisation (0) gsm(l) 

capextension (2) } 
"- } 

-- Example of transfer syntax, using the ExtensionField datatype as specified in clause 5. 
-- Assuming the value of the extension is set to TRUE, the extensions parameter becomes 
-- a Sequence of type {itu-t(O) identif ied-organization (4) organisation (0) gsm(l) 
-- capextension (2) } , criticality ENUMERATED ::= ignore ( ) and value [1] EXPLICIT BOOLEAN 
- - : : = TRUE . 

-- Use of ITU-T Recommendation Q.1400 [52] defined Extension is for further study. 

-- In addition the extension mechanism marker is used to identify the future minor additions 

--to CAP. 

firstExtension EXTENSION ::= { 
EXTENSION-SYNTAX NULL 
CRITICALITY ignore 
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IDENTIFIED BY global : {itu-t(O) identif ied-organization (4 ) organisation (0) gsm(l) 
capextension (2) } 

} 
-- f irstExtension is just an example. 

SupportedExtensions EXTENSION ::= { f irstExtension, ... 
-- full set of network operator extensions -- 

} 

-- SupportedExtension is the full set of the network operator extensions. 



PARAMETERS -BOUND ::= CLASS { 
StminAccessPointNameLength 
kmaxAccessPointNameLength 
kminAChBi 11 ingChargingLength 
kmaxAChBi 1 1 ingChargingLength 
kminAttributesLength 
SmaxAttributesLength 
SmaxBearerCapabilityLength 
kminCalledPartyBCDNumberLength 
kmaxCalledPartyBCDNumberLength 
kminCalledPartyNumberLength 
kmaxCalledPartyNumberLength 
kminCallingPartyNumberLength 
kmaxCallingPartyNumberLength 
kminCallResultLength 
SmaxCallResultLength 
SminCarrierLength 
SmaxCarrierLength 
SminCauseLength 
SmaxCauseLength 
SminDigitsLength 
SmaxDigitsLength 

&minFCIBillingChargingDataLength 
SmaxFCIBillingChargingDataLength 
kminFCIBi 11 ingChargingLength 
SmaxFCIBi 11 ingChargingLength 
SminGenericNumberLength 
SmaxGenericNumberLength 
SminGPRSCauseLength 
kmaxGPRSCauseLength 
&minIPSSPCapabilitiesLength 
SmaxIPSSPCapabilitiesLength 
kminLocationNumberLength 
kmaxLocationNumberLength 
kminLowLayerCompatibilityLength 
kmaxLowLayerCompatibilityLength 
SminMessageContentLength 
SmaxMessageContentLength 
SminOriginalCalledPartylDLength 
SmaxOriginalCalledPartylDLength 
kminPDPAddressLength 
kmaxPDPAddre s sLength 
SminRedirectingPartylDLength 
SmaxRedirectingPartylDLength 
kminScf IDLength 
kmaxScf IDLength 
kminSCIBi 11 ingChargingLength 
SmaxSCIBi 11 ingChargingLength 
StminTimeAndTimezoneLength 
kmaxTimeAndTime zoneLength 
knumOfBCSMEvents 

&numOf ChangeOf Posit ionControl Info 
tnumOfCSs 
knumOfSMSEvents 
knumOf GPRSEvent s 
&numOf Extensions 
knumOfGenericNumbers 
&numO fMessagelDs 



INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 



WITH SYNTAX 
MINIMUM 
MAXIMUM 
MINIMUM 
MAXIMUM 
MINIMUM 
MAXIMUM 
MAXIMUM 
MINIMUM 



{ 



FOR-ACCESS- POINT-NAME 
FOR- ACCESS- POINT-NAME 
FOR-ACH-BILLING- CHARGING 
FOR- ACH-BILLING- CHARGING 
FOR-ATTRIBUTES 
FOR-ATTRIBUTES 
FOR-BEARER- CAPABILITY 
FOR- CALLED- PARTY-BCD-NUMBER 



StminAccessPointNameLength 
SmaxAccessPointNameLength 
kminAChBi 11 ingChargingLength 
SmaxAChBi 1 1 ingChargingLength 
kminAttributesLength 
kmaxAttributesLength 
kmaxBearerCapabilityLength 
kminCalledPartyBCDNumberLength 
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MAXIMUM- FOR- CALLED- PARTY-BCD-NUMBER 

MINIMUM- FOR- CALLED- PARTY-NUMBER 

MAXIMUM- FOR- CALLED- PARTY-NUMBER 

MINIMUM- FOR- CALLING- PARTY-NUMBER 

MAXIMUM- FOR- CALLING- PARTY-NUMBER 

MINIMUM- FOR- CALL-RESULT 

MAXIMUM- FOR- CALL-RESULT 

MINIMUM- FOR- CARRIER 

MAXIMUM- FOR- CARRIER 

MINIMUM- FOR- CAUSE 

MAXIMUM- FOR- CAUSE 

MINIMUM- FOR-DIGITS 

MAXIMUM- FOR-DIGITS 

MINIMUM- FOR- FCI -BILLING- CHARGING-DATA 

MAXIMUM- FOR- FCI -BILLING- CHARGING-DATA 

MINIMUM- FOR- FCI -BILLING- CHARGING 

MAXIMUM- FOR- FCI -BILLING- CHARGING 

MINIMUM- FOR-GENERIC-NUMBER 

MAXIMUM- FOR-GENERIC-NUMBER 

MINIMUM- FOR-GPRS- CAUSE-LENGTH 

MAXIMUM- FOR-GPRS- CAUSE-LENGTH 

MINIMUM- FOR- I P-SSP- CAPABILITIES 

MAXIMUM- FOR- I P-SSP- CAPABILITIES 

MINIMUM- FOR-LOCATION-NUMBER 

MAXIMUM- FOR-LOCATION-NUMBER 

MINIMUM- FOR -LOW -LAYER- COMPATIBILITY 

MAXIMUM- FOR -LOW -LAYER- COMPATIBILITY 

MINIMUM- FOR-MESSAGE- CONTENT 

MAXIMUM- FOR-MESSAGE- CONTENT 

MINIMUM- FOR-ORIGINAL- CALLED- PARTY- ID 

MAXIMUM- FOR-ORIGINAL- CALLED- PARTY- ID 

MINIMUM- FOR- PDP-ADDRESS -LENGTH 

MAXIMUM- FOR- PDP-ADDRESS -LENGTH 

MINIMUM- FOR-REDIRECTING- ID 

MAXIMUM- FOR-REDIRECTING- ID 

MINIMUM- FOR-GSMSCF- ID 

MAXIMUM- FOR-GSMSCF- ID 

MINIMUM- FOR- SCI -BILLING- CHARGING 

MAXIMUM- FOR- SCI -BILLING- CHARGING 

MINIMUM- FOR-TIME-AND-TIMEZONE 

MAXIMUM- FOR-TIME-AND-TIMEZONE 

NUM-OF-BCSM-EVENT 

NUM-OF-CHANGE-OF- POSITION- CONTROL- INFO 

NUM-OF-CSS 

NUM -OF-SMS- EVENTS 

NUM- OF -GPRS -EVENTS 

NUM - OF - EXTENS I ONS 

NUM-OF-GENERIC-NUMBERS 

NUM-OF-MESSAGE-IDS 



SmaxCalledPartyBCDNumberLength 

kminCalledPartyNumberLength 

SmaxCalledPartyNumberLength 

kminCallingPartyNumberLength 

SmaxCallingPartyNumberLength 

kminCallResultLength 

SmaxCallResultLength 

kminCarrierLength 

kmaxCarrierLength 

SminCauseLength 

SmaxCauseLength 

SminDigitsLength 

SmaxDigitsLength 

&minFCIBillingChargingDataLength 

SmaxFCIBillingChargingDataLength 

kminFCIBillingChargingLength 

SmaxFCIBillingChargingLength 

SminGenericNumberLength 

SmaxGenericNumberLength 

SminGPRSCauseLength 

kmaxGPRSCauseLength 

SminlPSSPCapabilitiesLength 

SmaxIPSSPCapabilitiesLength 

SminLocationNumberLength 

SmaxLocationNumberLength 

kminLowLayerCompatibilityLength 

kmaxLowLayerCompatibilityLength 

SminMessageContentLength 

SmaxMessageContentLength 

kminOriginalCalledPartylDLength 

SmaxOriginalCalledPartylDLength 

kminPDPAddressLength 

kmaxPDPAddressLength 

SminRedirectingPartylDLength 

kmaxRedirectingPartylDLength 

kminScf IDLength 

kmaxScf IDLength 

kminSCIBillingChargingLength 

kmaxSCIBillingChargingLength 

SminTimeAndTime zoneLength 

kmaxTimeAndTimezoneLength 

SnumOfBCSMEvents 

&numOf ChangeOf Posit ionControl Info 

knumOfCSs 

knumOfSMSEvents 

knumOf GPRSEvent s 

&numOf Extensions 

knumOfGenericNumbers 

knumOf MessagelDs } 



cAPSpecificBoundSet PARAMETERS - BOUND ::= { 
MINIMUM- FOR-ACCESS- POINT-NAME 
MAXIMUM- FOR-ACCESS- POINT-NAME 
MINIMUM- FOR- ACH-BILLING- CHARGING 
MAXIMUM- FOR- ACH-BILLING- CHARGING 
MINIMUM- FOR- ATTRIBUTES 
MAXIMUM- FOR-ATTRIBUTES 
MAXIMUM- FOR-BEARER- CAPABILITY 
MINIMUM- FOR- CALLED- PARTY-BCD-NUMBER 
MAXIMUM- FOR- CALLED- PARTY-BCD-NUMBER 
MINIMUM- FOR- CALLED- PARTY-NUMBER 
MAXIMUM- FOR- CALLED- PARTY-NUMBER 
MINIMUM- FOR- CALLING- PARTY-NUMBER 
MAXIMUM- FOR- CALLING- PARTY-NUMBER 
MINIMUM- FOR- CALL-RESULT 
MAXIMUM- FOR- CALL-RESULT 
MINIMUM- FOR- CARRIER 
MAXIMUM- FOR- CARRIER 
MINIMUM- FOR- CAUSE 
MAXIMUM- FOR- CAUSE 
MINIMUM- FOR-DIGITS 
MAXIMUM- FOR-DIGITS 

MINIMUM- FOR- FCI -BILLING- CHARGING-DATA 
MAXIMUM- FOR- FCI -BILLING- CHARGING-DATA 
MINIMUM- FOR- FCI -BILLING- CHARGING 
MAXIMUM- FOR- FCI -BILLING- CHARGING 
MINIMUM- FOR-GENERIC-NUMBER 
MAXIMUM- FOR-GENERIC-NUMBER 
MINIMUM- FOR-GPRS -CAUSE-LENGTH 



1 

100 

5 

177 

2 

10 

11 

1 

41 

2 

18 

2 

10 

12 

193 

4 

4 

2 

32 

2 

16 

1 

160 

5 

225 

3 

11 

1 
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MAXIMUM- FOR-GPRS- CAUSE-LENGTH 

MINIMUM- FOR- I P-SSP- CAPABILITIES 

MAXIMUM- FOR- IP- SSP- CAPABILITIES 

MINIMUM- FOR-LOCATION-NUMBER 

MAXIMUM- FOR-LOCATION-NUMBER 

MINIMUM- FOR -LOW -LAYER- COMPATIBILITY 

MAXIMUM- FOR -LOW -LAYER- COMPATIBILITY 

MINIMUM- FOR-MESSAGE- CONTENT 

MAXIMUM- FOR-MESSAGE- CONTENT 

MINIMUM- FOR-ORIGINAL- CALLED- PARTY- ID 

MAXIMUM- FOR-ORIGINAL- CALLED- PARTY- ID 

MINIMUM- FOR- PDP-ADDRESS -LENGTH 

MAXIMUM- FOR- PDP-ADDRESS -LENGTH 

MINIMUM- FOR-REDIRECTING- ID 

MAXIMUM- FOR-REDIRECTING- ID 

MINIMUM- FOR-GSMSCF- ID 

MAXIMUM- FOR-GSMSCF- ID 

MINIMUM- FOR- SCI -BILLING- CHARGING 

MAXIMUM- FOR- SCI -BILLING- CHARGING 

MINIMUM- FOR-TIME-AND-TIMEZONE 

MAXIMUM- FOR-TIME-AND-TIMEZONE 

NUM-OF-BCSM-EVENT 

NUM- OF -CHANGE -OF- POSITION- CONTROL- INFO 

NUM-OF-CSS 

NUM -OF-SMS- EVENTS 

NUM -OF -GPRS -EVENTS 

NUM - OF - EXTENS I ONS 

NUM-OF-GENERIC-NUMBERS 

NUM-OF-MESSAGE-IDS 



1 

1 

4 

2 

10 

1 

16 

1 

127 

2 

10 

1 

63 

2 

10 

2 

10 

4 

225 



30 

10 

127 

10 

10 

10 

5 

16} 



END 



5.6 Object IDentifiers (IDs) 



CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules(3) cap-object-identifiers (100) version5(4)} 

DEFINITIONS ::= BEGIN 

-- This module assigns object identifiers for Modules, Packages, Contracts and ACs 
-- used by CAP 

-- For Modules from TC, ROS, 

tc-Messages OBJECT IDENTIFIER ::= 

{itu-t recommendation q 773 modules(2) messages(l) version3(3)} 

tc-NotationExtensions OBJECT IDENTIFIER ::= 

{itu-t recommendation q 775 modules (2) notation-extension (4) versionl(l)} 

ros-InformationObjects OBJECT IDENTIFIER ::= 

{ joint-iso-itu-t remote-operations (4) informationObjects (5) versionl(O)} 

-- For CAP Modules 

datatypes OBJECT IDENTIFIER ::= 

{itu-t (0) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 

cap-datatypes (52) version5(4)} 

errortypes OBJECT IDENTIFIER ::= 

{itu-t (0) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-errortypes (51) version5(4)} 

operationcodes OBJECT IDENTIFIER ::= 

{itu-t (0) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-operationcodes (53) version5 (4) } 

errorcodes OBJECT IDENTIFIER ::= 

{itu-t (0) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-errorcodes (57) version5(4)} 

classes OBJECT IDENTIFIER ::= 

{itu-t (0) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-classes (54) versions (4)} 

gsmSSF-gsmSCF-Operations OBJECT IDENTIFIER ::= 

{itu-t (0) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
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cap-gsmSSF-gsmSCF-ops-args (101) version5(4) } 
-- The Object Identifier ' gsmSSF-gsmSCF-Operations" is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Operation definitions related to call control. 

gsmSSF-gsmSCF-Protocol OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-gsmSSF-gsmSCF-pkgs-contracts-acs (102) version5(4) } 
-- The Object Identifier ' gsmSSF-gsmSCF-Protocol ' is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Protocol definitions related to call control. 

gsmSCF-gsmSRF-Operations OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-gsmSCF-gsmSRF-ops-args (103) version5(4) } 
-- The Object Identifier ' gsmSCF-gsmSRF-Operations ' is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Operation definitions related to gsmSRF control. 

gsmSCF-gsmSRF-Protocol OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-gsmSCF-gsmSRF-pkgs-contracts-acs (104) version5(4) } 
-- The Object Identifier ' gsmSCF-gsmSRF-Protocol ' is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Protocol definitions related to gsmSRF control. 

sms-Operations OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-SMS-ops-args (105) version5 (4) } 
-- The Object Identifier 'sms-Operations' is updated to version5(4) in Rel-6, so other 
-- modules can IMPORT Rel-6 Operation definitions related to SMS control. 

smsSSF-gsmSCF-Protocol OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-smsSSF-gsmSCF-pkgs-contracts-acs (106) version5(4) } 
-- The Object Identifier ' smsSSF-gsmSCF-Protocol ' is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Protocol definitions related to SMS control. 

gprsSSF-gsmSCF-Operations OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-GPRS-ops-args (107) version5 (4) } 
-- The Object Identifier ' gprsSSF-gsmSCF-Operations ' is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Operation definitions related to GPRS control. 

gprsSSF-gsmSCF-Protocol OBJECT IDENTIFIER ::= 

(itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umt s- network (1) modules (3) 
cap-gprsSSF-gsmSCF-pkgs-contracts-acs (108) version5(4) } 
-- The Object Identifier ' gprsSSF-gsmSCF-Protocol ' is updated to version5(4) in Rel-6, so 
-- other modules can IMPORT Rel-6 Protocol definitions related to GPRS control. 

id-CAP OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) cap4(22)} 

id-CAP3 OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) cap3(20)} 

id-CAPOE OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umts-network(l) cap40E(23)} 

id-CAP30E OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) cap30E(21)} 



id-ac 

id-acE 

id-ac3E 

id-as 

id-asE 

id-rosObject 

id-contract 

id-contract3 

id-contractE 

id-package 

id-packageE 



OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 



IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 



FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 



{id- 
{id- 
{id- 
{id- 
{id- 
{ id- 
fid- 
{id- 
{id- 
{id- 
f id- 



CAP 

CAPOE 

CAP30E 

CAP 

CAPOE 

CAP 

CAP 

CAP 3 

CAPOE 

CAP 

CAPOE 



ac(3) } 
ac(3) } 
ac(3) } 
as(5) } 
as(5) } 

rosObject (25) 
contract (26) } 
contract (26) } 
contract (26) } 
package (27) } 
package (27) } 



for ac, as, rosObject, contract and package, the values are identical to ITU-T Recommendation 
Q.1218 [49] 



ROS Objects 
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id-rosObj ect-gsmSCF 
id-rosObj ect-gsmSSF 
id-rosObj ect-gsmSRF 
id-rosObject-gprsSSF 
id-rosObject-smsSSF-V3 
id-rosObject-smsSSF-V4 



OBJECT IDENTIFIER 

OBJECT IDENTIFIER 

OBJECT IDENTIFIER 

OBJECT IDENTIFIER 

OBJECT IDENTIFIER 

OBJECT IDENTIFIER 



{id-rosObject 4} 

{id-rosObject 5} 

{id-rosObject 6} 

{id-rosObject 7} 

{id-rosObject 8} 

{id-rosObject 9} 



Application Contexts 



-- gsmSSF/gsmSCF AC 
id-ac-CAP-gsmSSF-scfGenericAC 
id-ac-CAP-gsmSSF-scfAssistHandof fAC 
id-ac-CAP-scf-gsmSSFGenericAC 

-- gsmSRF/gsmSCF AC 
id-ac-gsmSRF-gsmSCF 

-- gprsSSF/gsmSCF AC 

id-ac-CAP-gprsSSF-gsmSCF-AC 

id-ac-CAP-gsmSCF-gprsSSF-AC 

-- gprsSSF/gsmSCF or gsmSSF/gsmSCF AC 

id-ac-cap3-sms-AC 

id-ac-cap4-sms-AC 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



OBJECT IDENTIFIER 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



{id-acE 4} 
{id-acE 6} 
{id-acE 8} 

{id-ac 14} 



{id-ac3E 50} 
{id-ac3E 51} 



[id-ac3E 61} 
[id-acE 61} 



Contracts 



-- gsmSSF/gsmSCF Contracts 
id- CAPSsfToScf Generic 
id-CAPAssistHandof f ssfToScf 
id- CAPScfToSsf Generic 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



{id-contractE 3} 
{id-contractE 5} 
{id-contractE 6} 



-- gsmSRF/gsmSCF Contracts 
id-contract-gsmSRF-gsmSCF 



OBJECT IDENTIFIER 



id-contract 13 



-- gprsSSF/gsmSCF Contracts 

id-capGprsSsfTogsmScf 

id-capGsmScfToGprsSsf 

-- gprsSSF/gsmSCF or gsmSSF/gsmSCF Contracts 

id-cap3SmsSsfTogsmScf 

id-cap4SmsSsfTogsmScf 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



{id-contract 14} 
{id-contract 15} 



{id-contract3 16} 
{id-contract 16} 



-- Operation Packages 

-- gsmSSF/gsmSCF Operation Packages 

id-package- scf Activation 

id-package -gsmSRF-scf Act ivationOf Assist 

id-package- assistConnectionEstablishment 

id-package -genericDisconnectResource 

id-package-nonAssistedConnectionEstablishment 

id-package -connect 

id-package -callHandling 

id-package -bcsmEventHandling 

id-package- ssf CallProcessing 

id-package- scf Call Initiation 

id-package -timer 

id-package -billing 

id-package -charging 

id-package -traf f icManagement 

id-package -callReport 

id-package- signallingControl 

id-package- act ivityTe st 

id-package -cancel 

id-package -cphResponse 

id-package - except ionlnf orm 

id-package -playTone 

-- gsmSRF/gsmSCF Operation Packages 
id-package- spec ializedResourceControl 
id-package -gsmSRF- scf Cancel 



OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 



IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 



FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 
id-pa 



ckage 11 
ckage 15 
ckage 16 
ckage 17 
ckage 18 
ckage 19 
ckageE 2 
ckage 21 
ckageE 24 
ckage 2 5 
ckage 2 6 
ckage 2 7 
ckage 2 8 
ckage 2 9 
ckage 32 
ckage 33 
ckage 34 
ckageE 36 
ckage 3 7 
ckage 38 
ckage 3 9 



id-package 42 
id-package 43 



-- gprsSSF/gsmSCF Operation Packages 
id-package -gprsContinue 



OBJECT IDENTIFIER 



[id-package 4£ 
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id-package -gprsExceptionlnformat ion 
id-package -gprsScfActivat ion 
id-package -gprsConnect 
id-package -gprsRe lease 
id-package -gprsEventHandling 
id-package -gprsTimer 
id-package -gprsBil ling 
id-package -gprsCharging 
id-package -gprsActivityTest 
id-package -gprsCancel 
id-package -gprsChargeAdvice 



OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 



IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 



FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 



-- gprsSSF/gsmSCF or gsmSSF/gsmSCF Operation Packages 

id-package- smsActivation OBJECT IDENTIFIER 

id-package- smsConnect OBJECT IDENTIFIER 

id-package- smsContinue OBJECT IDENTIFIER 

id-package- smsRelease OBJECT IDENTIFIER 

id-package- smsEventHandling OBJECT IDENTIFIER 

id-package-smsBilling OBJECT IDENTIFIER 

id-package- smsTimer OBJECT IDENTIFIER 



id-pac 
id-pac 
id-pac 
id-pac 
id-pac 
id-pac 
id-pac 
id-pac 
id-pac 
id-pac 
id-pac 



kage 50 
kage 51 
kage 52 
kage 53 
kage 54 
kage 55 
kage 56 
kage 57 
kage 58 
kage 59 
kage 6 



id-package 61 

id-package 62 

id-package 63 

id-package 64 

id-package 65 

id-package 66 

id-package 67 



Abstract Syntaxes 



-- gsmSSF/gsmSCF Abstract Syntaxes 
id-as-gsmSSF-scfGenericAS 
id-as-assistHandof f -gsmSSF-scfAS 
id-as-scf -gsmSSFGenericAS 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



{id-asE 4) 
{id-asE 6j 
{id-asE 7} 



-- gsmSRF/gsmSCF Abstract Syntaxes 
id-as-basic-gsmSRF-gsmSCF 



OBJECT IDENTIFIER 



[id-as 14} 



-- gprsSSF/gsmSCF Abstract Syntaxes 

id-as-gprsSSF-gsmSCF-AS 

id-as-gsmSCF-gprsSSF-AS 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



{id-as 50} 
{id-as 51} 



-- gprsSSF/gsmSCF or gsmSSF/gsmSCF Abstract Syntaxes 

id-as-smsSSF-gsmSCF-AS OBJECT IDENTIFIER ::= {id-as 61} 



5.7 



User Abort Data 



CAP-U-ABORT-Data {itu-t(O) identif ied-organization (4 ) etsi{0) mobileDomain (0) umt s- network (1) 
modules(3) cap-u-abort-data (110) version5(4)} 



DEFINITIONS 



BEGIN 



id-CAP-U-ABORT-Reason OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(0) 
mobileDomain (0) umts-Network (1) as(l) cap-u-abort-reason (2) version3(2)} 



cAP-U-ABORT-Reason-Abstract- Syntax ABSTRACT- SYNTAX 
id-CAP-U-ABORT-Reason} 



CAP-U-ABORT-REASON ::= ENUMERATED { 

no-reason-given (1) 

application-timer-expired (2) 

not-allowed-procedures (3) 

abnormal-processing (4) 

congestion (5) 

invalid-reference (6) 

missing-reference (7) 

overlapping-dialogue (8) 



{ CAP-U-ABORT-REASON IDENTIFIED BY 



application- timer- expired 
not-allowed-procedures 



abnormal -processing 
congestion 

invalid- reference 



mis sing- reference 



shall be set when application timer (e.g. Tssf) is expired, 
shall be set when received signal is not allowed in CAP 
procedures . 

For example, when a class 4 operation is received from the 
gsmSCF and the operation is not allowed in gsmSSF FSM. 
(gsmSSF FSM cannot continue state transition) . (e.g. ReleaseCall 
operation received in Waiting for End of Temporary Connection 
state. ) 

shall be set when abnormal procedures occur at entity action. 
shall be set when requested resource is unavailable due to 
congestion at TC user (CAP) level. 

shall be set if the received destinationRef erence is unknown or 
for a known destination Reference the received originationRef erence 
does not match with the stored originationRef erence . 
This abort reason is used for CAP defined GPRS-Ref erenceNumber . 
shall be set when the destinationRef erence or the 
originationRef erence is absent in the received message but is 
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required to be present according to the procedures in 

subclause 14.1.7. 

This abort reason is used for CAP defined GPRS-Ref erenceNumber . 
-- overlapping-dialogue shall be used by the gprsSSF to indicate to the gsmSCF that a 

specific instance already has a TC dialogue open. This error 

cause is typically obtained when both the gsmSCF and gprsSSF 

open a new dialogue at the same time. 
-- no-reason-given shall be set when any other reasons above do not apply 

END -- of CAP-U-ABORT-Data 



6 Circuit Switched Call Control 

6.1 gsmSSF/CCF - gsmSCF Interface 



6.1 .1 Operations and arguments 



CAP-gsmSSF-gsmSCF-ops-args {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-gsmSSF-gsmSCF-ops-args (101) version5(4)} 

DEFINITIONS IMPLICIT TAGS ::= BEGIN 

-- This module contains the operations and operation arguments used for the 
-- gsmSSF - gsmSCF interface, for the control of circuit switched calls. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

errortypes, 

datatypes, 

operationcodes , 

classes, 

tc-Messages, 

ros-Inf ormationObjects 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

OPERATION 
FROM Remote -Operations -Information- Objects ros-Inf ormationObjects 

CallingPartysCategory, 

HighLayerCompatibility, 

LegID, 

Redirectionlnformation, 

ServiceKey 
FROM CSl-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) inDomain(l) in-network (1) 
modules(O) csl-datatypes (2) versionl(O)} 

MiscCalllnfo 
FROM CS2-datatypes {itu-t(O) identif ied-organization (4) etsi(0) inDomain(l) in-network (1) 
cs2(20) modules (0) in-cs2-datatypes (0) versionl(O)} 

Ext-BasicServiceCode , 

IMEI, 

IMSI, 

ISDN-AddressString 
FROM MAP-CommonDataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-CommonDataTypes (18) version9(9)} 

CUG- Index, 

CUG-Interlock, 

CUG- Info, 

Locationlnformation, 

MS-Classmark2, 

SubscriberState, 

SupportedCamelPhases , 

Of feredCamel4 Functionalities 
FROM MAP-MS-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-MS-DataTypes (11) version9(9)} 

CallRef erenceNumber, 
SuppressionOf Announcement , 
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UU-Data 
FROM MAP-CH-DataTypes {itu-t(O) identif ied-organization (4 ) etsi{0) mobileDomain (0) 
gsm-Network (1) modules (3) map-CH-DataTypes (13) version9(9)} 

PARAMETERS - BOUND 
FROM CAP-classes classes 

opcode-activityTest , 

opcode - applyCharging , 

opcode - applyChargingReport , 

opcode- assistRequest Instruct ions, 

opcode -callGap, 

opcode-calllnf ormationReport , 

opcode-calllnf ormationRequest , 

opcode-cancel , 

opcode -collect Information, 

opcode-connect , 

opcode - connectToRe source , 

opcode-continue , 

opcode-continueWithArgument , 

opcode -disconnectForwardConnect ion, 

opcode-dFCWithArgument , 

opcode -disconnecting, 

opcode -entityRe leased, 

opcode -establishTemporaryConnect ion, 

opcode - eventReportBCSM , 

opcode -furnishCharginglnf ormat ion, 

opcode- initialDP, 

opcode -initiateCallAt tempt, 

opcode -moveLeg, 

opcode -playTone, 

opcode - re leaseCall, 

opcode-requestReportBCSMEvent , 

opcode -resetTimer, 

opcode -sendCharginglnf ormat ion, 

opcode- splitLeg 
FROM CAP-operationcodes operationcodes 

-- The CAP Operation identifiers for CAP V4 in Rel-6 are the same as the CAP Operation 
-- identifiers for CAP V4 in Rel-5. 

AChBillingChargingCharacteristics { } , 

AdditionalCallingPartyNumber { } , 

Alert ingPat tern, 

AChChargingAddress { } , 

AssistingSSPIPRoutingAddress { } , 

BCSMEvent { } , 

BCSM-Failure, 

BearerCapability { } , 

Burst, 

CalledPartyNumber { } , 

CalledPartyBCDNumber { } , 

CallingPartyNumber { } , 

CallResult {}, 

CallSegmentID {}, 

CallSegmentToCancel { } , 

CallSegmentFailure { } , 

Carrier, 

Cause { } , 

CGEncountered , 

ChargeNumber { } , 

ControlType, 

CorrelationID { } , 

DestinationRoutingAddress { } , 

EventSpecif icInformationBCSM { } , 

EventTypeBCSM , 

Extensions { } , 

FCIBillingChargingCharacteristics { } , 

GapCriteria { } , 

Gaplndicators , 

GapTreatment , 

GenericNumbers { } , 

InvokelD, 

IPRoutingAddress {}, 

IPSSPCapabilities {}, 

legl, 

leg2, 

LegOrCallSegment { } , 

LocationNumber { } , 
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LowLayerCompatibility { } , 

MonitorMode, 

NAOlilnfo, 

OCSIApplicable, 

OriginalCalledPartylD { } , 

Receivings ide ID, 

RedirectingPartylD { } , 

RequestedlnformationList { } , 

Requestedlnf ormationTypeList , 

ScfID {}, 

SCIBillingChargingCharacteristics { } , 

SendingSidelD, 

ServicelnteractionlndicatorsTwo, 

TimeAndTimezone { } , 

TimerlD, 

TimerValue 
FROM CAP-datatypes datatypes 

-- For Rel-6, the CAP-datatypes module is updated to version5(4); Object Identifier 'datatypes' 
-- is also updated to version5(4) . As a result, the present module uses Rel-6 data type definitions. 

cancelFailed, 

eTCFailed, 

missingCustomerRecord, 

missingParameter, 

parameterOutOf Range , 

requestedlnf oError, 

systemFailure, 

taskRefused, 

unexpectedComponentSequence , 

unexpectedDataValue , 

unexpectedParameter, 

unknownLegID , 

unknownCSID 
FROM CAP-errortypes errortypes 

-- For Rel-6, the CAP-errortypes module is updated to version5 (4) ; Object Identifier 
-- 'errortypes' is also updated to version5(4) . As a result, the present module uses Rel-6 
-- error type definitions. 



activityTest OPERATION ;:= { 

RETURN RESULT TRUE 

CODE opcode-activityTest} 

-- Direction: gsmSCF -> gsmSSF, Timer: T at 

-- This operation is used to check for the continued existence of a relationship 
-- between the gsmSCF and gsmSSF, assist gsmSSF or gsmSRF . If the relationship is 
-- still in existence, then the gsmSSF will respond. If no reply is received, 
-- then the gsmSCF will assume that the gsmSSF, assist gsmSSF or gsmSRF has failed 
-- in some way. 

applyCharging { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT ApplyChargingArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

unexpectedComponentSequence | 
unexpectedParameter | 
unexpectedDataValue | 
parameterOutOfRange | 
systemFailure | 
taskRefused | 
unknownLegID | 
unknownCSID} 
CODE opcode-applyCharging} 

-- Direction: gsmSCF -> gsmSSF, Timer: T ac 

-- This operation is used for interacting from the gsmSCF with the gsmSSF charging mechanisms. 
-- The ApplyChargingReport operation provides the feedback from the gsmSSF to the gsmSCF. 

ApplyChargingArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

aChBillingChargingCharacteristics [0] AChBillingChargingCharacteristics {bound}, 
partyToCharge [2] SendingSidelD DEFAULT SendingSidelD : legl, 

extensions [3] Extensions {bound} OPTIONAL, 

aChChargingAddress [5 0] AChChargingAddress {bound} 

DEFAULT legID : SendingSidelD : legl , 



The partyToCharge parameter indicates the party in the call to which the ApplyCharging operation 
shall be applied. 
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applyChargingReport { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT ApplyChargingReportArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

unexpectedComponentSequence | 
unexpectedParameter | 
unexpectedDataValue | 
unknownCSID | 
unknownLegID | 
parameterOutOfRange | 
systemFailure | 
taskRefused} 
CODE opcode-applyChargingReport } 

-- Direction: gsmSSF -> gsmSCF, Timer: T acr 

-- This operation is used by the gsmSSF to report to the gsmSCF the occurrence of a 
-- specific charging event as requested by the gsmSCF using the ApplyCharging operation. 

ApplyChargingReportArg { PARAMETERS - BOUND : bound} ::= CallResult {bound} 

assistRequestlnstructions { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT AssistRequestlnstructionsArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingCustomerRecord | 

missingParameter | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter} 
CODE opcode-assistRequestlnstructions } 

-- Direction: gsmSSF -> gsmSCF or gsmSRF -> gsmSCF, Timer: T ari 

-- This operation is used when there is an assist procedure and may be 

-- sent by the gsmSSF or gsmSRF to the gsmSCF. This operation is sent by the 

-- assisting gsmSSF to gsmSCF, when the initiating gsmSSF has set up a connection to 

-- the gsmSRF or to the assisting gsmSSF as a result of receiving an 

-- EstablishTemporaryConnection from 

-- the gsmSCF. 

-- Refer to clause 11 for a description of the procedures associated with this operation. 

AssistRequestlnstructionsArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 
correlationID [0] CorrelationID {bound}, 

iPSSPCapabilities [2] IPSSPCapabilities {bound}, 

extensions [3] Extensions {bound} OPTIONAL, 

}" 
-- OPTIONAL denotes network operator specific use. The value of the correlationID may be the 
-- Called Party Number supplied by the initiating gsmSSF. 

callGap {PARAMETERS -BOUND : bound} OPERATION ::= { 

ARGUMENT CallGapArg {bound} 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode -callGap} 

-- Direction: gsmSCF -> gsmSSF, Timer: T cq 

-- This operation is used to request the gsmSSF to reduce the rate at which specific service 
-- requests are sent to the gsmSCF. 

CallGapArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

gapCriteria [0] GapCriteria {bound}, 

gaplndicators [1] Gaplndicators, 

controlType [2] ControlType OPTIONAL, 

gapTreatment [3] GapTreatment {bound} OPTIONAL, 

extensions [4] Extensions {bound} OPTIONAL, 

}" 
-- OPTIONAL denotes network operator optional. If gapTreatment is not present, then the gsmSSF will 
-- use a default treatment depending on network operator implementation. 

calllnformationReport { PARAMETERS - BOUND : bound} OPERATION ::= { 

ARGUMENT Calllnf ormationReportArg {bound} 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode-calllnf ormationReport } 

-- Direction: gsmSSF -> gsmSCF, Timer: T c j_ r p 

-- This operation is used to send specific call information for a single call party to the gsmSCF as 
-- requested by the gsmSCF in a previous Calllnf ormationRequest . 
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CalllnformationReportArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

requestedlnformationList [0] RequestedlnformationList {bound}, 

extensions [2] Extensions {bound} OPTIONAL, 

legID [3] ReceivingSidelD DEFAULT receivingSidelD : leg2 , 



ARGUMENT 
RETURN RESULT 
ERRORS 



calllnformationRequest { PARAMETERS - BOUND : bound} OPERATION ::= { 

Cal 1 Inf ormat ionReque s t Arg { bound } 

FALSE 

{missingParameter | 

parameterOutOfRange | 

requestedlnfoError | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownLegID } 

opcode-calllnf ormationRequest } 
gsmSCF -> gsmSSF, Timer: T c j_ r g 
-- This operation is used to request the gsmSSF to record specific information about a single 
-- call party and report it to the gsmSCF (with a CalllnformationReport operation) . 

CalllnformationRequestArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

requestedlnformationTypeList [0] RequestedlnformationTypeList , 
extensions [2] Extensions {bound} 



CODE 
Direction 



OPTIONAL, 



legID 



[3] SendingSidelD DEFAULT sendingSidelD : leg2 , 



-- OPTIONAL denotes network operator optional. 

cancel { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT CancelArg {bound} 
FALSE 

{cancelFailed | 
missingParameter | 
taskRefused | 
unknownCSID} 
opcode-cancel } 
gsmSCF -> gsmSSF, or gsmSCF -> gsmSRF, Timer: T can 
This operation cancels the correlated previous operation or all previous requests. The following 
operations can be canceled: PlayAnnouncement , PromptAndCollectUserlnformation. 



RETURN RESULT 
ERRORS 



CODE 
Direction: 



CancelArg { PARAMETERS - BOUND 
invokelD 
allRequests 
callSegmentToCancel 



bound} : := CHOICE { 

[0] InvokelD, 

[1] NULL, 

[2] CallSegmentToCancel {bound} 



-- The InvokelD has the same value as that which was used for the operation to be cancelled. 

collectlnformation { PARAMETERS - BOUND : bound} OPERATION: := { 
ARGUMENT Collectlnf ormationArg {bound} 

RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 
SystemFailure 
TaskRefused | 

UnexpectedComponentSequence | 
UnexpectedDataValue | 
UnexpectedParameter} 
CODE opcode-collectlnformation} 

-- Direction: gsmSCF-> gsmSSF, Timer: T c j_ 

-- This operation is used to request the gsmSSF to perform the call 
-- processing actions to prompt a calling party for additional digits. 



Collect Inf ormationArg { PARAMETERS - BOUND 
extensions 



bound} ::= SEQUENCE{ 

[0] Extensions {bound} OPTIONAL, 



connect { PARAMETERS - BOUND : bound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



ConnectArg {bound} 
FALSE 

{missingParameter | 
parameterOutOfRange 
systemFailure | 
taskRefused | 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 



65 



ETSI TS 129 078 V8.2.1 (2010-04) 



unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownLegID } 
CODE opcode-connect} 

Direction: gsmSCF-> gsmSSF, Timer: T con 

This operation is used to request the gsmSSF to perform the call processing actions 
to route or forward a call to a specified destination. 



ConnectArg { PARAMETERS - BOUND : bound} 
destinationRoutingAddress 
alert ingPat tern 
originalCalledPartylD 
extensions 
carrier 

callingPartysCategory 
redirect ingPartylD 
redirectionlnformation 
genericNumbers 

servicelnteractionlndicatorsTwo 
chargeNumber 
legToBeConnected 
cug- Interlock 
cug-OutgoingAccess 
suppress ionOf Announcement 
oCSIApplicable 
naOlilnfo 
bor-InterrogationRequested 



SEQUENCE { 

Des t inat ionRout ingAddre s s { bound } 
Alert ingPat tern 
OriginalCalledPartylD {bound} 

Extensions {bound} 

Carrier {bound} 

CallingPartysCategory 

RedirectingPartylD {bound} 

Redirectionlnformation 

GenericNumbers {bound} 

ServicelnteractionlndicatorsTwo 

ChargeNumber {bound} 

LegID 

CUG- Interlock 

NULL 

Suppress ionOf Announcement 

OCSIApplicable 

NAOlilnfo 

NULL 



[0] 


[1] 


[6] 


[10] 


[11] 


[28] 


[29] 


[30] 


[14] 


[15] 


[19] 


[21] 


[31] 


[32] 


[55] 


[56] 


[57] 


[58] 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



suppress-N-CSI 



[59] NULL 



OPTIONAL 



na-Info is included at the discretion of the gsmSCF operator. 



connectToResource { PARAMETERS - BOUND : bound} OPERATION 



{ 



ARGUMENT ConnectToResourceArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

systemFailure | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter | 
unknownCSID} 
CODE opcode- connectToResource } 

Direction: gsmSCF -> gsmSSF, Timer: T ctr 

This operation is used to connect a call segment from the gsmSSF to the 
gsmSRF . 



ConnectToResourceArg { PARAMETERS - BOUND 
resourceAddress CHOICE { 
ipRout ingAddre s s 
none 



bound} ::= SEQUENCE { 

[0] IPRoutingAddress {bound}, 
[ 3 ] NULL 



extensions 

servicelnteractionlndicatorsTwo 

callSegmentID 



[4] Extensions {bound} 

[7] ServicelnteractionlndicatorsTwo 

[50] CallSegmentID {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



continue OPERATION ::= { 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode -continue} 

-- Direction: gsmSCF -> gsmSSF, Timer: T cue 

-- This operation is used to request the gsmSSF to proceed with call processing at the 
-- DP at which it previously suspended call processing to await gsmSCF instructions 
-- (i.e. proceed to the next point in call in the BCSM) . The gsmSSF continues call 
-- processing without substituting new data from gsmSCF. 

continueWithArgument { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT ContinueWithArgumentArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownLegID | 
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unknownCSID} 
CODE opcode-continueWithArgument } 

Direction: gsmSCF -> gsmSSF, Timer: T cwa 

This operation is used to request the gsmSSF to proceed with call processing at the 
DP at which it previously suspended call processing to await gsmSCF instructions 
(i.e. proceed to the next point in call in the BCSM) . The gsmSSF continues call 
processing with the modified call setup information as received from the gsmSCF. 



ContinueWithArgumentArg { PARAMETERS - BOUND 

[ 



alert ingPat tern 

extensions 

servicelnteractionlndicatorsTwo 

callingPartysCategory 

genericNumbers 

cug- Interlock 

cug-OutgoingAccess 

chargeNumber 

carrier 

suppress ionOf Announcement 

naOlilnfo 

bor-InterrogationRequested 

suppress-O-CSI 

continueWithArgumentArgExtension 



bound} ::= SEQUENCE { 
Alert ingPat tern 
Extensions {bound} 
ServicelnteractionlndicatorsTwo 

CallingPartysCategory 

GenericNumbers {bound} 

CUG- Interlock 

NULL 

ChargeNumber {bound} 

Carrier {bound} 

Suppress ionOf Announcement 

NAOlilnfo 

NULL 

NULL 

ContinueWithArgumentArgExtension 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
'bound} OPTIONAL, 



ContinueWithArgumentArgExtension 
suppress-D-CSI 
suppress-N-CSI 
suppressOutgoingCallBarring 
legOrCallSegment 



PARAMETERS -BOUND : bound} ::= SEQUENCE 
[ ] NULL 
[1] NULL 
[2] NULL 
[3] LegOrCallSegment {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



disconnectForwardConnection OPERATION ::= { 
RETURN RESULT FALSE 
ERRORS {systemFailure | 

taskRefused | 

unexpectedComponentSequence } 
CODE opcode -disconnectForwardConnection} 

-- Direction: gsmSCF -> gsmSSF, Timer: T d f c 

-- This operation is used to disconnect a forward temporary connection or a connection to a 
-- resource. Refer to clause 11 for a description of the procedures associated with this operation. 



disconnectForwardConnectionWithArgument { PARAMETERS - BOUND ; bound} OPERATION 



{ 



ARGUMENT DisconnectForwardConnectionWithArgumentArg {bound} 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownCSID} 
CODE opcode-dFCWithArgument} 

Direction gsmSCF -> gsmSSF, Timer T dfcwa 

This operation is used to disconnect a forward temporary connection or a connection to a 
resource. Refer to clause 11 for a description of the procedures associated with this operation. 



DisconnectForwardConnectionWithArgumentArg { PARAMETERS - BOUND : bound} 
callSegmentID [1] CallSegmentID {bound} 

extensions [2] Extensions {bound} 



SEQUENCE { 



OPTIONAL, 
OPTIONAL, 



disconnectLeg 
ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 
Direction: 



PARAMETERS -BOUND : bound} OPERATION 
DisconnectLegArg {bound} 
TRUE 

{missingParameter | 
systemFailure | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter | 
unknownLegID } 
opcode -disconnectLeg} 
> gsmSSF, Timer T dl 



gsmSCF 
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-- This operation is used by the gsmSCF to release a specific leg associated with the call and 
-- retain any other legs not specified in the DisconnectLeg. Refer to clause 11 for a description 
-- of the procedures associated with this operation. 

DisconnectLegArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

legToBeReleased [0] LegID, 

releaseCause [1] Cause {bound} OPTIONAL, 

extensions [2] Extensions {bound} OPTIONAL, 



entityReleased { PARAMETERS - BOUND : bound} OPERATION ::= { 

ARGUMENT EntityReleasedArg {bound} 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode-entityReleased} 

-- Direction: gsmSSF -> gsmSCF, Timer: T er 

-- This operation is used by the gsmSSF to inform the gsmSCF of an error or exception 

EntityReleasedArg { PARAMETERS - BOUND : bound} ::= CHOICE { 

callSegmentFailure [0] CallSegmentFailure {bound}, 

bCSM-Failure [1] BCSM-Failure {bound} 

} 

establishTemporaryConnection { PARAMETERS - BOUND ; bound} OPERATION ::= { 
ARGUMENT EstablishTemporaryConnectionArg {bound} 
RETURN RESULT FALSE 
ERRORS {eTCFailed | 

missingParameter | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownCSID} 
CODE opcode -establishTemporaryConnection} 

-- Direction: gsmSCF -> gsmSSF, Timer: T etc 

-- This operation is used to create a connection to a resource for a limited period 

-- of time (e.g. to play an announcement, to collect user information) ; it implies 

-- the use of the assist procedure. Refer to clause 11 for a description of the 

-- procedures associated with this operation. 

EstablishTemporaryConnectionArg { PARAMETERS - BOUND ; bound} ::= SEQUENCE { 

assistingSSPIPRoutingAddress [0] AssistingSSPIPRoutingAddress {bound}, 

correlationID [1] CorrelationID {bound} OPTIONAL, 

scfID [3] ScfID {bound} OPTIONAL, 

extensions [4] Extensions {bound} OPTIONAL, 

carrier [5] Carrier {bound} OPTIONAL, 

servicelnteractionlndicatorsTwo [6] ServicelnteractionlndicatorsTwo OPTIONAL, 

callSegmentID [7] CallSegmentID {bound} OPTIONAL, 

naOlilnfo [50] NAOlilnfo OPTIONAL, 

chargeNumber [51] ChargeNumber {bound} OPTIONAL, 

originalCalledPartylD [52] OriginalCalledPartylD {bound} OPTIONAL, 

callingPartyNumber [53] CallingPartyNumber {bound} OPTIONAL 

} 

eventReportBCSM { PARAMETERS - BOUND : bound} OPERATION ::= { 

ARGUMENT EventReportBCSMArg {bound} 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode -eventReportBCSM} 

-- Direction: gsmSSF -> gsmSCF, Timer: T erb 

-- This operation is used to notify the gsmSCF of a call-related event (e.g. BCSM 
-- events such as 0_Busy or 0_No_Answer) previously requested by the gsmSCF in a 
-- RequestReportBCSMEvent operation. 

EventReportBCSMArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

eventTypeBCSM [0] EventTypeBCSM, 

eventSpecif icInformationBCSM [2] EventSpecif icInformationBCSM {bound} OPTIONAL, 

legID [3] ReceivingSidelD OPTIONAL, 

miscCalllnfo [4] MiscCalllnfo DEFAULT {messageType request}, 

extensions [5] Extensions {bound} OPTIONAL, 



furnishCharginglnformation { PARAMETERS - BOUND : bound} OPERATION 
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ARGUMENT FurnishCharginglnf ormationArg {bound} 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownLegID } 
CODE opcode -f urnishCharginglnf ormat ion} 

-- Direction: gsmSCF -> gsmSSF, Timer: T fci 

-- This operation is used to request the gsmSSF to generate, register a call record 

-- or to include some information in the default call record. 

-- The registered call record is intended for off line charging of the call. 

FurnishCharginglnformationArg { PARAMETERS - BOUND : bound} ::= 
FCIBillingChargingCharacteristics {bound} 

initialDP { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT InitialDPArg {bound} 
RETURN RESULT FALSE 

ERRORS {missingCustomerRecord | 

missingParameter | 
parameterOutOfRange | 
systemFailure | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter} 
CODE opcode-initialDP} 

-- Direction: gsmSSF -> gsmSCF, Timer: T-j_<jp 
-- This operation is used after a TDP to indicate request for service. 



InitialDPArg { PARAMETERS - BOUND : bound} 
serviceKey 
calledPartyNumber 
callingPartyNumber 
callingPartysCategory 
cGEncountered 
iPSSPCapabilities 
locationNumber 
originalCalledPartylD 
extensions 

highLayerCompatibility 
additionalCallingPartyNumber 
bearerCapability 
eventTypeBCSM 
redirect ingPartylD 
redirect ionlnf ormat ion 
cause 

servicelnteractionlndicatorsTwo 
carrier 
cug- Index 
cug- Interlock 
cug-OutgoingAccess 
iMSI 

subscriberState 
locat ionlnf ormat ion 
ext-basicServiceCode 
callRef erenceNumber 
mscAddress 

calledPartyBCDNumber 
t imeAndTime zone 
callForwardingSS- Pending 
initialDPArgExtension 



[0] 


[2] 


[3] 


[5] 


[7] 


[8] 


[10] 


[12] 


[15] 


[23] 


[25] 


[27] 


[28] 


[29] 


[30] 


[17] 


[32] 


[37] 


[45] 


[46] 


[47] 


[50] 


[51] 


[52] 


[53] 


[54] 


[55] 


[56] 


[57] 


[58] 


[59] 



SEQUENCE { 
ServiceKey , 

CalledPartyNumber {bound} OPTIONAL, 

CallingPartyNumber {bound} OPTIONAL, 

CallingPartysCategory OPTIONAL, 

CGEncountered OPTIONAL, 

IPSSPCapabilities {bound} OPTIONAL, 

LocationNumber {bound} OPTIONAL, 

OriginalCalledPartylD {bound} OPTIONAL, 

Extensions {bound} OPTIONAL, 

HighLayerCompatibility OPTIONAL, 
AdditionalCallingPartyNumber {bound} OPTIONAL, 

BearerCapability {bound} OPTIONAL, 

EventTypeBCSM OPTIONAL, 

RedirectingPartylD {bound} OPTIONAL, 

Redirectionlnformation OPTIONAL, 

Cause {bound} OPTIONAL, 

ServicelnteractionlndicatorsTwo OPTIONAL, 

Carrier {bound} OPTIONAL, 

CUG- Index OPTIONAL, 

CUG- Interlock OPTIONAL, 

NULL OPTIONAL, 

IMSI OPTIONAL, 

SubscriberState OPTIONAL, 

Locationlnformation OPTIONAL, 

Ext-BasicServiceCode OPTIONAL, 

CallRef erenceNumber OPTIONAL, 

ISDN-AddressString OPTIONAL, 

CalledPartyBCDNumber {bound} OPTIONAL, 

TimeAndTimezone {bound} OPTIONAL, 

NULL OPTIONAL, 

InitialDPArgExtension {bound} OPTIONAL, 



InitialDPArgExtension { PARAMETERS - BOUND 

gmscAddress [0 

forwardingDestinationNumber [1 

ms-Classmark2 [2 

iMEI [3 

supportedCamelPhases [4 

of f eredCamel4Functionalities [5 

bearerCapability2 [6 

ext-basicServiceCode2 [7 

highLayerCompatibility2 [8 

lowLayerCompatibility [9 



bound} ::= SEQUENCE { 
ISDN-AddressString 
CalledPartyNumber {bound} 
MS-Classmark2 
IMEI 

SupportedCamelPhases 
Of feredCame 14 Functionalities 
BearerCapability {bound} 
Ext-BasicServiceCode 
HighLayerCompatibility 
LowLayerCompatibility {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
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lowLayerCompatibility2 



[10] LowLayerCompatibility {bound} 



OPTIONAL, 



enhancedDialledServicesAl lowed 

uu-Data 

col lee tlnf ormationAl lowed 



[11] NULL 
[12] UU-Data 
[13] NULL 



OPTIONAL, 
OPTIONAL, 
OPTIONAL 



If iPSSPCapabilities is not present then this denotes that a colocated gsmSRF is not 

supported by the gsmSSF. If present, then the gsmSSF supports a colocated gsmSRF capable 

of playing announcements via elementaryMessagelDs and variableMessages, the playing of 

tones and the collection of DTMF digits. Other supported capabilities are explicitly 

detailed in the IPSSPCapabilities parameter itself. 

Carrier is included at the discretion of the gsmSSF operator. 

The UserCSGInformation is conveyed in the Locationlnformation. The encoding of the parameter is 

as defined in 3GPP TS 29.002 [11] . 



initiateCallAttempt { PARAMETERS - BOUND : bound} OPERATION 
ARGUMENT InitiateCallAttemptArg {bound} 
RESULT InitiateCallAttemptRes {bound} 

ERRORS {missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter 



{ 



CODE opcode-initiateCallAttempt} 

-- Direction: gsmSCF -> gsmSSF, Timer Tj_ 

-- This operation is used to instruct the gsmSSF to create a new call to a call party using the 
-- address information provided by the gsmSCF. 

InitiateCallAttemptArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

destinationRoutingAddress [0] DestinationRoutingAddress {bound}, 

extensions [4] Extensions {bound} OPTIONAL, 

legToBeCreated [5] LegID OPTIONAL, 

newCallSegment [6] CallSegmentID {bound} OPTIONAL, 

callingPartyNumber [30] CallingPartyNumber {bound} OPTIONAL, 

callReferenceNumber [51] CallRef erenceNumber OPTIONAL, 

gsmSCFAddress [52] ISDN-AddressString OPTIONAL, 

suppress-T-CSI [53] NULL OPTIONAL, 



InitiateCallAttemptRes { PARAMETERS - BOUND : bound} ::= SEQUENCE { 
supportedCamelPhases [0] SupportedCamelPhases 

of f eredCamel4Functionalities [1] Of f eredCamel4Functionalities 
extensions [2] Extensions {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



moveLeg { PARAMETERS - BOUND : bound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



{ bound } 



I 



MoveLegArg 
TRUE 

{missingParameter 
systemFailure | 
taskRefused | 

unexpectedComponentSequence 
unexpectedDataValue | 
unexpectedParameter | 
unknownLegID } 
opcode -moveLeg} 
gsmSCF -> gsmSSF, Timer: T ml 

This operation is used by the gsmSCF to move 
within the same call segment association. 



CODE 
Direction 



a leg from one call segment to another call segment 



MoveLegArg { PARAMETERS - BOUND 
leglDToMove 
extensions 



bound} ::= SEQUENCE{ 
[0] LegID, 
[2] Extensions {bound} 



OPTIONAL, 



playTone { PARAMETERS - BOUND : bound} OPERATION ::= 
ARGUMENT PlayToneArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 

systemFailure | 

unexpectedComponentSequence | 
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unexpectedDataValue | 
unexpectedParameter | 
unknownLegID | 
unknownCSID} 
CODE opcode-playTone} 

-- Direction: gsmSCF -> gsmSSF, Timer: T t 

-- This operation is used to play tones to either a leg or a call segment using 
-- the MSC's tone generator. 

PlayToneArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

legOrCallSegment [0] LegOrCallSegment {bound}, 

bursts [1] Burst, 

extensions [2] Extensions {bound} OPTIONAL, 



releaseCall { PARAMETERS - BOUND : bound} OPERATION ::= { 

ARGUMENT ReleaseCallArg {bound} 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode-releaseCall} 

-- Direction: gsmSCF ->gsmSSF, Timer: T rc 

-- This operation is used to tear down an existing call at any phase of the call for all parties 
-- involved in the call. 

ReleaseCallArg { PARAMETERS - BOUND : bound} ::= Cause {bound} 

-- A default value of decimal 31 (normal unspecified) shall be given. 

requestReportBCSMEvent { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT RequestReportBCSMEventArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 
systemFailure | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter | 
unknownLegID } 
CODE opcode - requestReportBCSMEvent } 

-- Direction: gsmSCF -> gsmSSF, Timer: T rr j3 

-- This operation is used to request the gsmSSF to monitor for a call-related event 
-- (e.g. BCSM events such as 0_Busy or 0_No_Answer) and to send a notification 
-- to the gsmSCF when the event is detected. 

-- NOTE: 

-- Every EDP must be explicitly armed by the gsmSCF via a RequestReportBCSMEvent operation. 

-- No implicit arming of EDPs at the gsmSSF after reception of any operation (different 

-- from RequestReportBCSMEvent) from the gsmSCF is allowed. 

RequestReportBCSMEventArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

bcsmEvents [0] SEQUENCE SIZE (1 .. bound . knumOf BCSMEvents) OF 

BCSMEvent {bound}, 
extensions [2] Extensions {bound} OPTIONAL, 

}" 
-- Indicates the BCSM related events for notification. 

resetTimer { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT ResetTimerArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter | 
unknownCSID} 
CODE opcode-resetTimer} 

-- Direction: gsmSCF -> gsmSSF, Timer: T rt 
-- This operation is used to request the gsmSSF to refresh an application timer in the gsmSSF. 

ResetTimerArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

timerlD [0] TimerlD DEFAULT tssf, 

timervalue [1] TimerValue, 

extensions [2] Extensions {bound} OPTIONAL, 

callSegmentID [3] CallSegmentID {bound} OPTIONAL, 
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sendCharginglnformation { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT SendCharginglnf ormationArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

unexpectedComponentSequence | 
unexpectedParameter | 
parameterOutOfRange | 
systemFailure | 
taskRefused | 
unexpectedDataValue | 
unknownLegID } 
CODE opcode -sendCharginglnformation} 

-- Direction: gsmSCF -> gsmSSF, Timer: T sc j_ 

-- This operation is used to instruct the gsmSSF on the charging information to send by the gsmSSF. 
-- The charging information can either be sent back by means of signalling or internal 
-- if the gsmSSF is located in the local exchange. In the local exchange 
-- this information may be used to update the charge meter or to create a standard call record. 

SendCharginglnformationArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

sCIBillingChargingCharacteristics [0] SCIBillingChargingCharacteristics {bound}, 

partyToCharge [1] SendingSidelD, 

extensions [2] Extensions {bound} OPTIONAL, 



splitLeg {PARAMETERS -BOUND : bound} OPERATION ::= { 
ARGUMENT SplitLegArg {bound} 
RETURN RESULT TRUE 
ERRORS {missingParameter | 

unexpectedComponentSequence | 

unexpectedParameter | 

unexpectedDataValue | 

systemFailure | 

taskRefused | 

unknownLegID } 
CODE opcode-splitLeg} 

-- Direction: gsmSCF -> gsmSSF, Timer T sl 

-- This operation is used by the gsmSCF to separate a leg from its source call segment and 
-- place it in a new call segment within the same call segment association. 

SplitLegArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

legToBeSplit [0] LegID, 

newCallSegment [1] CallSegmentID {bound} OPTIONAL, 

extensions [2] Extensions {bound} OPTIONAL, 



The following value ranges apply for operation specific timers in CAP: 

short: 1 s - 10 s 

medium: 1 s - 60 s 

long: 1 s - 30 minutes 

Table 6-1 lists all operation timers and the value range for each timer. The definitive value for each operation timer may 
be network specific and has to be defined by the network operator. 
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Table 6-1 : Timer value ranges 



Operation Name 


Timer 


value range 


ActivityTest 


Tat 


Short 


ApplyCharging 


T ac 


Short 


ApplyChargingReport 


T acr 


Short 


AssistRequestlnstructions 


T ari 


Short 


Collectlnformation 


Tci 


Short 


CalllnformationReport 


T cirp 


Short 


CalllnformationRequest 


T cirq 


Short 


Cancel 


T can 


Short 


CallGap 


T cg 


Short 


Connect 


T con 


Short 


ConnectToResource 


T ctr 


Short 


Continue 


T cue 


Short 


ContinueWithArgument 


T cwa 


Short 


DisconnectForwardConnectionWithArgument 


T dfcwa 


Short 


DisconnectLeg 


T dl 


Short 


EntityReleased 


Ter 


Short 


DisconnectForwardConnection 


T dfc 


Short 


EstablishTemporaryConnection 


T etc 


Medium 


EventReportBCSM 


T erb 


Short 


FurnishCharginglnformation 


T fci 


Short 


InitialDP 


T idp 


Short 


InitiateCallAttempt 


T ica 


Short 


MoveLeg 


T ml 


Short 


PlayTone 


T pt 


Short 


ReleaseCall 


Trc 


Short 


RequestReportBCSMEvent 


'nb 


Short 


ResetTimer 


T rt 


Short 


SendCharginglnformation 


T sci 


Short 


SplitLeg 


Tsl 


Short 



6.1 .2 gsmSSF/gsmSCF packages, contracts and ACs 
6.1.2.1 gsmSSF/gsmSCFASN.1 module 

CAP-gsmSSF-gsmSCF-pkgs-contracts-acs {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-gsmSSF-gsmSCF-pkgs-contracts-acs (102) version5(4)} 



DEFINITIONS 



BEGIN 



-- This module specifies the Operation Packages, Contracts, Application Contexts 
-- and Abstract Syntaxes used for the gsmSSF - gsmSCF interface, for the control of 
-- circuit switched calls. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

PARAMETERS - BOUND , 

cAPSpecif icBoundSet 
FROM CAP-classes classes 

-- Elements that exist in cAPSpecif icBoundSet in Rel-5 are not changed in Rel-6. As a 
-- result, the value range of data type definitions in Rel-5 are not changed in Rel-6. 

CONTRACT, 
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OPERATION- PACKAGE , 
OPERATION 
FROM Remote -Operations -Information- Objects ros-InformationObjects 

TCMessage {} 
FROM TCAPMes sages tc -Messages 

APPLICATION- CONTEXT, 
dialogue -abstract -syntax 
FROM TC-Notation-Extensions tc-NotationExtensions 

activityTest , 

applyCharging { } , 

applyChargingReport { } , 

assistRequestlnstructions { } , 

callGap {}, 

calllnformationReport { } , 

calllnformationRequest { } , 

cancel { } , 

collectlnformation { } , 

connect { } , 

connectToResource { } , 

continue, 

continueWithArgument { } , 

disconnectForwardConnection, 

disconnectForwardConnectionWithArgument { } , 

disconnecting { } , 

entityReleased { } , 

establishTemporaryConnection { } , 

eventReportBCSM { } , 

furnishCharginglnformation { } , 

initialDP {}, 

initiateCallAttempt { } , 

moveLeg { } , 

playTone { } , 

releaseCall { } , 

requestReportBCSMEvent { } , 

resetTimer { } , 

sendCharginglnformation { } , 

splitLeg { } 
FROM CAP-gsmSSF-gsmSCF-ops-args gsmSSF-gsmSCF-Operations 

-- Object Identifier ' gsmSSF-gsmSCF-Operations ' is updated to version5{4) in Rel-6. As 
-- a result, the present module, ' CAP-gsmSSF-gsmSCF-pkgs-contracts-acs ' , IMPORTS CAP 
-- Operation definitions from CAP-gsmSSF-gsmSCF-ops-args version5(4) . Operation 
-- definitions are used in the ABSTRACT SYNTAX definitions and in the OPERATION PACKAGE 
-- definitions. 

playAnnouncement { } , 

promptAndCollectUserlnformation { } , 

specializedResourceReport 
FROM CAP-gsmSCF-gsmSRF-ops-args gsmSCF-gsmSRF-Operations- - Object Identifier ' gsmSCF-gsmSRF- 
Operations' is updated to version5(4) in Rel-6. AS 

-- a result, the present module, ' CAP-gsmSSF-gsmSCF-pkgs-contracts-acs ' , IMPORTS CAP 
-- Operation definitions from CAP-gsmSCF-gsmSRF-ops-args version5(4) . Operation 
-- definitions are used in the ABSTRACT SYNTAX definitions and in the OPERATION PACKAGE 
-- definitions. 

specializedResourceControlPackage { } 
FROM CAP-gsmSCF-gsmSRF-pkgs- contract s-acs gsmSCF-gsmSRF- Protocol 

-- Object Identifier ' gsmSCF-gsmSRF- Protocol ' is updated to version5(4) in Rel-6. As a 
-- result, the present module, ' CAP-gsmSSF-gsmSCF-pkgs-contracts-acs ' , IMPORTS CAP Operation 
-- Package definitions from CAP-gsmSCF-gsmSRF-pkgs-contracts-acs version5(4) . Operation 
-- Package definitions are used in the CONTRACT definitions. 

id-ac-CAP-gsmSSF-scfGenericAC, 
id-ac-CAP-gsmSSF-scfAssistHandof fAC, 
id-ac-CAP-scf-gsmSSFGenericAC, 
-- The APPLICATION-CONTEXT Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

id-CAPSsfToScf Generic, 
id-CAPAssistHandof f ssfToScf , 
id-CAPScfToSsf Generic, 
-- The CONTRACT Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

id-as-gsmSSF-scfGenericAS, 
id-as-scf -gsmSSFGenericAS, 
id-as-assistHandof f -gsmSSF-scf AS, 
-- The ABSTRACT- SYNTAX Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 
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id-package -scf Activation, 
id-package -gsmSRF-scf Act ivationOf Assist , 
id-package- assistConnectionEstablishment, 
id-package -genericDisconnectResource, 
id-package -nonAssistedConnectionEstablishment, 
id-package-connect , 
id-package -callHandling, 
id-package- be smEventHandling, 
id-package- ssf CallProcessing, 
id-package -scf Call Initiation, 
id-package -timer, 
id-package -billing, 
id-package- charging , 
id-package-traf f icManagement , 
id-package-callReport , 
id-package- signallingControl, 
id-package-activityTest , 
id-package-cancel , 
id-package-cphResponse , 
id-package- except ionlnform, 
id-package-playTone , 
-- The OPERATION- PACKAGE Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

classes, 

ros- Inf ormationOb j ects , 

tc-Messages, 

tc-NotationExtensions , 

gsmSSF-gsmSCF-Operations , 

gsmSCF-gsmSRF-Operations , 
-- Object Identifiers gsmSSF-gsmSCF-Operations and gsmSCF-gsmSRF-Operations are updated 
-- to version5(4) in Rel-6. As a result, the present module, ' CAP-gsmSSF-gsmSCF-pkgs- 
-- contracts-acs ' , IMPORTS Rel-6 versions of the CAP Operation definitions. 

gsmSCF-gsmSRF- Protocol 
-- Object Identifier gsmSCF-gsmSRF-Protocol is updated to version5(4) in Rel-6. As a result, 
-- the present module IMPORTS Rel-6 versions of the CAP Operation Package definitions. 

FROM CAP-object-identif iers {itu-t{0) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5 (4) } ; 

-- Application Contexts 

-- CAP V4 Rel-5 and CAP V4 Rel-6 use the same Application Context version. The CONTRACT 
-- and ABSTRACT SYNTAXES for the call control related Application Contexts, however, are 
-- defined in Rel-6. This is needed to use parameter definitions that are defined in Rel-6. 

-- Refer to ITU-T Recommendation Q.775 for the formal definition of APPLICATION-CONTEXT. 

-- The structured DIALOGUE MODE is defined in ITU-T Recommendation Q.771; the 

-- dialogue-abstract-syntax ABSTRACT SYNTAX is defined in ITU-T Recommendation Q.775. 

capssf-scfGenericAC APPLICATION-CONTEXT ::= { 

CONTRACT capSsfToScfGeneric 

DIALOGUE MODE structured 

ABSTRACT SYNTAXES {dialogue -abstract- syntax | 

gsmSSF-scfGenericAbs tract Syntax} 

APPLICATION CONTEXT NAME id-ac-CAP-gsmSSF- scf GenericAC } 
-- 'capSsfToScfGeneric' and ' gsmSSF-scfGenericAbstractSyntax' are defined in the present 
-- module. 

capssf-scfAssistHandoffAC APPLICATION-CONTEXT ::= { 

CONTRACT capAssistHandoffssfToScf 

DIALOGUE MODE structured 

ABSTRACT SYNTAXES {dialogue-abstract- syntax | 

assistHandof f -gsmSSF- scf Abstract Syntax} 

APPLICATION CONTEXT NAME id-ac-CAP-gsmSSF- scf AssistHandof fAC} 
-- 'capAssistHandoffssfToScf' and ' assistHandof f-gsmSSF-scfAbstractSyntax' are defined in 
-- the present module. 

capscf-ssfGenericAC APPLICATION-CONTEXT ::= { 

CONTRACT capScfToSsfGeneric 

DIALOGUE MODE structured 

ABSTRACT SYNTAXES {dialogue-abstract- syntax | 

scf -gsmSSFGenericAbs tract Syntax} 

APPLICATION CONTEXT NAME id-ac-CAP- scf -gsmSSFGenericAC } 
-- 'capScfToSsfGeneric' and ' scf -gsmSSFGenericAbstractSyntax' are defined in the present 
-- module. 
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Contracts 

The CONTRACT definitions are updated for Rel-6, due to the fact that the individual 

OPERATION- PACKAGE definitions are updated in Rel-6. 



capSsfToScf Generic CONTRACT ::= { 

-- dialogue initiated by gsmSSF with InitialDP Operation 



INITIATOR CONSUMER OF 



RES PONDER CONSUMER OF 



■} I 



{exceptionlnformPackage {cAPSpecif icBoundSet } 
scfActivationPackage {cAPSpecif icBoundSet} } 
{activityTestPackage | 
assistConnectionEstablishmentPackage {cAPSpecif icBoundSet } | 
bcsmEventHandlingPackage {cAPSpecif icBoundSet } | 
billingPackage {cAPSpecif icBoundSet } | 
callHandlingPackage {cAPSpecif icBoundSet } | 
callReportPackage {cAPSpecif icBoundSet } | 
cancelPackage {cAPSpecif icBoundSet } | 
chargingPackage {cAPSpecif icBoundSet } | 
connectPackage {cAPSpecif icBoundSet } | 
cphResponsePackage {cAPSpecif icBoundSet } | 
genericDisconnectResourcePackage {cAPSpecif icBoundSet } | 
nonAssistedConnectionEstablishmentPackage {cAPSpecif icBoundSet } | 
playTonePackage {cAPSpecif icBoundSet } | 
signallingControlPackage {cAPSpecif icBoundSet } | 
specializedResourceControlPackage {cAPSpecif icBoundSet } | 
ssf CallProcessingPackage {cAPSpecif icBoundSet } | 
timerPackage {cAPSpecif icBoundSet } | 
traf f icManagementPackage {cAPSpecif icBoundSet } | 
scf CalllnitiationPackage {cAPSpecif icBoundSet } } 
ID id-CAPSsfToScf Generic} 

The OPERATION- PACKAGES are defined in the present module, except for 

specializedResourceControlPackage, which is defined in CAP-gsmSCF-gsmSRF-pkgs-contracts-acs . 



capAssistHandoffssfToScf CONTRACT 

-- dialogue initiated by gsmSSF with AssistRequestlnstructions 



INITIATOR CONSUMER OF 
RES PONDER CONSUMER OF 



{gsmSRF-scfActivationOfAssistPackage {cAPSpecif icBoundSet } } 
{activityTestPackage | 
cancelPackage {cAPSpecif icBoundSet } | 

genericDisconnectResourcePackage {cAPSpecif icBoundSet } | 
nonAssistedConnectionEstablishmentPackage {cAPSpecif icBoundSet } 
specializedResourceControlPackage {cAPSpecif icBoundSet } | 
timerPackage {cAPSpecif icBoundSet} } 
ID id-CAPAssistHandoffssfToScf } 

The OPERATION- PACKAGES are defined in the present module, except for 

specializedResourceControlPackage, which is defined in CAP-gsmSCF-gsmSRF-pkgs-contracts-acs . 



capScfToSsf Generic CONTRACT ::= { 

-- dialogue initiated by gsmSCF with InitiateCallAttempt , 



Generic Case 



INITIATOR CONSUMER OF 



{activityTestPackage | 

assistConnectionEstablishmentPackage {cAPSpecif icBoundSet } | 

bcsmEventHandlingPackage {cAPSpecif icBoundSet } | 

billingPackage {cAPSpecif icBoundSet } | 

callHandlingPackage {cAPSpecif icBoundSet } | 

callReportPackage {cAPSpecif icBoundSet } | 

cancelPackage {cAPSpecif icBoundSet } | 

chargingPackage {cAPSpecif icBoundSet } | 

connectPackage {cAPSpecif icBoundSet } | 

cphResponsePackage {cAPSpecif icBoundSet } | 

genericDisconnectResourcePackage {cAPSpecif icBoundSet } | 

nonAssistedConnectionEstablishmentPackage {cAPSpecif icBoundSet } | 

playTonePackage {cAPSpecif icBoundSet } | 

scf CalllnitiationPackage {cAPSpecif icBoundSet } | 

specializedResourceControlPackage {cAPSpecif icBoundSet } | 

ssf CallProcessingPackage {cAPSpecif icBoundSet } | 

timerPackage {cAPSpecif icBoundSet } } 

{exceptionlnformPackage {cAPSpecif icBoundSet } } 

id-CAPScfToSsf Generic} 

The OPERATION- PACKAGES are defined in the present module, except for 

specializedResourceControlPackage, which is defined in CAP-gsmSCF-gsmSRF-pkgs-contracts-acs . 



RES PONDER CONSUMER OF 
ID 



-- Operation Packages 

-- The OPERATION- PACKAGE definitions are updated for Rel-6, due to the fact that the individual 

-- OPERATION definitions are updated in Rel-6. The OPERATION definitions are IMPORTED from 

-- CAP-gsmSSF-gsmSCF-ops-args and from CAP-gsmSCF-gsmSRF-ops-args . 

scfActivationPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {initialDP {bound}} 
ID id-package-scfActivation} 
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gsmSRF-scfActivationOfAssistPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { assistRequestlnstructions {bound}} 
ID id-package -gsmSRF- scf Act ivationOf Assist } 

assistConnectionEstablishmentPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { establishTemporaryConnection {bound}} 
ID id-package-assistConnectionEstablishment } 

genericDisconnectResourcePackage { PARAMETERS - BOUND ; bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {disconnectForwardConnection | 

disconnectForwardConnectionWithArgument {bound} } 
ID id-package-genericDisconnectResource } 

nonAssistedConnectionEstablishmentPackage { PARAMETERS - BOUND ; bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { connectToResource {bound}} 
ID id-package-nonAssistedConnectionEstablishment } 

connectPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {connect {bound}} 
ID id-package-connect} 

callHandlingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {releaseCall {bound}} 
ID id-package-callHandling} 

bcsmEventHandlingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { requestReportBCSMEvent {bound}} 
SUPPLIER INVOKES { eventReportBCSM {bound}} 
ID id-package-bcsmEventHandling} 

ssfCallProcessingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 

CONSUMER INVOKES { collectlnf ormation | continueWithArgument {bound} | continue} 
ID id-package-ssf CallProcessing} 

scfCalllnitiationPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { initiateCallAttempt {bound}} 
ID id-package-scf Calllnitiation} 

timerPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {resetTimer {bound}} 
ID id-package-timer} 

billingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { f urnishCharginglnf ormation {bound}} 
ID id-package-billing} 

chargingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { applyCharging {bound}} 
SUPPLIER INVOKES { applyChargingReport {bound}} 
ID id-package-charging} 

trafficManagementPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {callGap {bound}} 
ID id-package-traf f icManagement } 

callReportPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { calllnf ormationRequest {bound}} 
SUPPLIER INVOKES { calllnf ormationReport {bound}} 
ID id-package-callReport } 

signallingControlPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { sendCharginglnf ormation {bound}} 
ID id-package- signallingControl} 

activityTestPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { activityTest } 
ID id-package-activityTest } 

cancelPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {cancel {bound}} 
ID id-package-cancel} 

cphResponsePackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {continueWithArgument {bound} | 

disconnectLeg {bound} | 

moveLeg {bound} | 

splitLeg {bound}} 
ID id-package-cphResponse} 
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exceptionlnformPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { entityReleased {bound}} 
ID id-package-exceptionlnform} 

playTonePackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {playTone {bound}} 
ID id-package-playTone} 

-- Abstract Syntaxes 

-- SsfToScfGeneridnvokable and SsfToScfGenericReturnable use OPERATION definitions with 
-- version5{4). As a result, GenericSSF-gsmSCF-PDUs uses version5{4) OPERATION definitions. 
-- As a subsequent result, gsmSSF-scfGenericAbstractSyntax uses version5(4) OPERATION 
-- definitions. That ABSTRACT- SYNTAX is used in the capssf -scf GenericAC APPLICATION-CONTEXT 
-- definition (CAP from gsmSSF to gsmSCF) . 

gsmSSF-scfGenericAbstractSyntax ABSTRACT- SYNTAX ::= { 

GenericSSF-gsmSCF-PDUs 

IDENTIFIED BY id-as-gsmSSF- scf GenericAS } 
-- 'GenericSSF-gsmSCF-PDUs' is defined in the present module. 

GenericSSF-gsmSCF-PDUs ::= TCMessage {{SsfToScfGeneridnvokable}, 

{SsfToScfGenericReturnable} } 
-- 'SsfToScfGeneridnvokable' and 'SsfToScfGenericReturnable' are defined in the present module. 

SsfToScfGeneridnvokable OPERATION ::= { 
activityTest | 

applyCharging {cAPSpecif icBoundSet } | 
applyChargingReport {cAPSpecif icBoundSet} | 
calllnformationReport {cAPSpecif icBoundSet } | 
calllnformationRequest {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
connect {cAPSpecif icBoundSet } | 
continueWithArgument {cAPSpecif icBoundSet } | 
connectToResource {cAPSpecif icBoundSet } | 
collectlnformation | 
disconnectForwardConnection | 

disconnectForwardConnectionWithArgument {cAPSpecif icBoundSet } | 
disconnecting {cAPSpecif icBoundSet } | 
entityReleased {cAPSpecif icBoundSet } | 
establishTemporaryConnection {cAPSpecif icBoundSet } | 
eventReportBCSM {cAPSpecif icBoundSet} | 
furnishCharginglnf ormation {cAPSpecif icBoundSet } | 
initialDP {cAPSpecif icBoundSet } | 
initiateCallAttempt {cAPSpecif icBoundSet } | 
moveLeg {cAPSpecif icBoundSet } | 
releaseCall {cAPSpecif icBoundSet} | 
requestReportBCSMEvent {cAPSpecif icBoundSet } | 
resetTimer {cAPSpecif icBoundSet } | 
sendCharginglnf ormation {cAPSpecif icBoundSet } | 
splitLeg {cAPSpecif icBoundSet} | 
playAnnouncement {cAPSpecif icBoundSet } | 
playTone {cAPSpecif icBoundSet } | 

promptAndCollectUserlnf ormation {cAPSpecif icBoundSet } | 
specializedResourceReport 

} 
-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args . 

SsfToScfGenericReturnable OPERATION ::= { 
activityTest | 

applyCharging {cAPSpecif icBoundSet } | 
applyChargingReport {cAPSpecif icBoundSet } | 
callGap {cAPSpecif icBoundSet} | 
calllnformationRequest {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
connect {cAPSpecif icBoundSet } | 
connectToResource {cAPSpecif icBoundSet } | 
collectlnformation | 
continue | 

continueWithArgument {cAPSpecif icBoundSet } | 
disconnectForwardConnection | 

disconnectForwardConnectionWithArgument {cAPSpecif icBoundSet } | 
disconnectLeg {cAPSpecif icBoundSet } | 
entityReleased {cAPSpecif icBoundSet } | 
establishTemporaryConnection {cAPSpecif icBoundSet } | 
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furnishCharginglnformation {cAPSpecif icBoundSet } | 
initialDP {cAPSpecif icBoundSet} | 
initiateCallAttempt {cAPSpecif icBoundSet} | 
moveLeg {cAPSpecif icBoundSet } | 
releaseCall {cAPSpecif icBoundSet } | 
requestReportBCSMEvent {cAPSpecif icBoundSet } | 
resetTimer {cAPSpecif icBoundSet } | 
sendCharginglnformation {cAPSpecif icBoundSet } | 
splitLeg {cAPSpecif icBoundSet} | 
playAnnouncement {cAPSpecif icBoundSet } | 
playTone {cAPSpecif icBoundSet } | 
promptAndCollectUserlnformation {cAPSpecif icBoundSet } 

} 
-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args . 

-- AssistHandof f ssfToScf Invokable and AssistHandof f ssfToScf Returnable use OPERATION definitions 

-- with version5(4). As a result, AssistHandof fsSF-gsmSCF-PDUs uses version5{4) OPERATION 

-- definitions. As a subsequent result, assistHandof f -gsmSSF-scf AbstractSyntax uses version5(4) 

-- OPERATION definitions. That ABSTRACT- SYNTAX is used in the capssf-scf AssistHandof f AC 

-- APPLICATION-CONTEXT definition (CAP from assist gsmSSF to gsmSCF) . 

assistHandof f-gsmSSF-scfAbstractSyntax ABSTRACT-SYNTAX ::= { 

AssistHandof fsSF-gsmSCF-PDUs 

IDENTIFIED BY id-as-assistHandof f -gsmSSF- scf AS } 
-- 'AssistHandof f sSF-gsmSCF-PDUs ' is defined in the present module. 

AssistHandof fsSF-gsmSCF-PDUs ::= TCMessage { {AssistHandof f ssfToScf Invokable} , 

{AssistHandof f ssfToScf Returnable } } 
-- 'AssistHandof f ssfToScf Invokable ' and 'AssistHandof f ssfToScfReturnable ' are defined in the 
-- present module. 

AssistHandof f ssfToScf Invokable OPERATION ::= { 
activityTest | 

assistRequestlnstructions {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
connectToResource {cAPSpecif icBoundSet } | 
disconnectForwardConnection | 
playAnnouncement {cAPSpecif icBoundSet } | 
promptAndCollectUserlnformation {cAPSpecif icBoundSet } | 
resetTimer {cAPSpecif icBoundSet } | 
special izedResourceReport 

} 
-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args . 

AssistHandof f ssfToScfReturnable OPERATION ::= { 
activityTest | 

assistRequestlnstructions {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
connectToResource {cAPSpecif icBoundSet } | 
disconnectForwardConnection | 
playAnnouncement {cAPSpecif icBoundSet } | 
promptAndCollectUserlnformation {cAPSpecif icBoundSet } | 
resetTimer {cAPSpecif icBoundSet } 

} 
-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args . 

-- ScfToSsfGenericInvokable and ScfToSsfGenericReturnable use OPERATION definitions 

-- with version5(4). As a result, GenericSCF-gsmSSF-PDUs uses version5(4) OPERATION 

-- definitions. As a subsequent result, scf -gsmSSFGenericAbstractSyntax uses version5(4) 

-- OPERATION definitions. That ABSTRACT- SYNTAX is used in the capscf -ssf GenericAC 

-- APPLICATION-CONTEXT definition (CAP from gsmSCF to gsmSSF) . 

scf -gsmSSFGenericAbstractSyntax ABSTRACT-SYNTAX ::= { 

GenericSCF-gsmSSF-PDUs 

IDENTIFIED BY id-as- scf -gsmSSFGenericAS } 
-- 'GenericSCF-gsmSSF-PDUs' is defined in the present module. 

GenericSCF-gsmSSF-PDUs ::= TCMessage {{ScfToSsfGenericInvokable}, 

{ScfToSsfGenericReturnable} } 
-- 'ScfToSsfGenericInvokable' and 'ScfToSsfGenericReturnable' are defined in the 
-- present module. 

ScfToSsfGenericInvokable OPERATION ::= { 
activityTest | 
applyCharging {cAPSpecif icBoundSet } | 
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applyChargingReport {cAPSpecif icBoundSet } | 

calllnformationRequest {cAPSpecif icBoundSet} | 

cancel {cAPSpecif icBoundSet } | 

collectlnformation | 

connect {cAPSpecif icBoundSet } | 

connectToResource {cAPSpecif icBoundSet } | 

continue | 

continueWithArgument {cAPSpecif icBoundSet } | 

disconnectForwardConnection | 

disconnectForwardConnectionWithArgument {cAPSpecif icBoundSet } | 

disconnectLeg {cAPSpecif icBoundSet } | 

establishTemporaryConnection {cAPSpecif icBoundSet } | 

furnishCharginglnf ormation {cAPSpecif icBoundSet } | 

initiateCallAttempt {cAPSpecif icBoundSet} | 

moveLeg {cAPSpecif icBoundSet } | 

playTone {cAPSpecif icBoundSet } | 

releaseCall {cAPSpecif icBoundSet } | 

requestReportBCSMEvent {cAPSpecif icBoundSet } | 

resetTimer {cAPSpecif icBoundSet } | 

sendCharginglnf ormation {cAPSpecif icBoundSet } | 

splitLeg {cAPSpecif icBoundSet} | 

playAnnouncement {cAPSpecif icBoundSet } | 

promptAndCollectUserlnf ormation {cAPSpecif icBoundSet } 

} 
-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args . 

ScfToSsfGenericReturnable OPERATION ::= { 
activityTest | 

applyCharging {cAPSpecif icBoundSet } | 
applyChargingReport {cAPSpecif icBoundSet } | 
calllnformationReport {cAPSpecif icBoundSet } | 
calllnformationRequest {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
connect {cAPSpecif icBoundSet } | 
connectToResource {cAPSpecif icBoundSet } | 
disconnectForwardConnection | 

disconnectForwardConnectionWithArgument {cAPSpecif icBoundSet } | 
disconnectLeg {cAPSpecif icBoundSet } | 
entityReleased {cAPSpecif icBoundSet } | 
establishTemporaryConnection {cAPSpecif icBoundSet } | 
eventReportBCSM {cAPSpecif icBoundSet} | 
furnishCharginglnf ormation {cAPSpecif icBoundSet } | 
initiateCallAttempt {cAPSpecif icBoundSet } | 
moveLeg {cAPSpecif icBoundSet } | 
requestReportBCSMEvent {cAPSpecif icBoundSet } | 
resetTimer {cAPSpecif icBoundSet } | 
sendCharginglnf ormation {cAPSpecif icBoundSet } | 
splitLeg {cAPSpecif icBoundSet} | 
playAnnouncement {cAPSpecif icBoundSet } | 
playTone {cAPSpecif icBoundSet } | 

promptAndCollectUserlnf ormation {cAPSpecif icBoundSet } | 
special izedResourceReport 

} 
-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args. 



6.2 gsmSCF/gsmSRF interface 

6.2.1 gsmSCF/gsmSRF operations and arguments 

CAP-gsmSCF-gsmSRF-ops-args {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-gsmSCF-gsmSRF-ops-args (103) version5(4)} 

DEFINITIONS IMPLICIT TAGS ::= BEGIN 

-- This module contains the operations and operation arguments used for the 
-- gsmSRF - gsmSCF interface, for the control of circuit switched calls. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 
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OPERATION 
FROM Remote -Operations -Information- Objects ros-InformationObjects 

opcode -playAnnouncement, 

opcode -promptAndCol lee tUser Information, 

opcode- spec ializedResourceReport 
FROM CAP-operationcodes operationcodes 

-- The CAP Operation identifiers for CAP V4 in Rel-6 are the same as the CAP Operation 
-- identifiers for CAP V4 in Rel-5. 

CallSegmentID {}, 

Collectedlnfo, 

Digits {}, 

Extensions { } , 

InformationToSend { } 
FROM CAP-datatypes datatypes 

-- For Rel-6, the CAP-datatypes module is updated to version5 (4) ; Object Identifier 'datatypes' 
-- is also updated to version5(4) . As a result, the present module uses Rel-6 data type definitions. 

canceled, 

improperCallerResponse, 

missingParameter, 

parameterOutOf Range , 

systemFailure, 

taskRefused, 

unavailableResource, 

unexpectedComponentSequence , 

unexpectedDataValue , 

unexpectedParameter, 

unknownCSID 
FROM CAP-errortypes errortypes 

-- For Rel-6, the CAP-errortypes module is updated to version5 (4) ; Object Identifier 
-- 'errortypes' is also updated to version5(4) . As a result, the present module uses Rel-6 
-- error type definitions. 

PARAMETERS - BOUND 
FROM CAP-classes classes 

ros- Inf ormationOb j ects , 

operationcodes , 

datatypes, 

errortypes, 

classes 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 



playAnnouncement { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT PlayAnnouncementArg {bound} 
RETURN RESULT FALSE 
ERRORS {canceled | 

missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unavailableResource | 

unknownCSID} 
LINKED { specializedResourceReport } 

CODE opcode-playAnnouncement } 

-- Direction: gsmSCF -> gsmSRF, Timer: T 

-- This operation is to be used after Establish Temporary Connection (assist procedure 

-- with a second gsmSSF) or a Connect to Resource (no assist) operation. It may be used 

-- for inband interaction with a mobile station, or for interaction with an ISDN user. 

-- In the former case, the gsmSRF is usually collocated with the gsmSSF for standard 

-- tones (congestion tone...) or standard announcements. 

-- In the latter case, the gsmSRF is always collocated with the gsmSSF in the switch. 

-- Any error is returned to the gsmSCF. The timer associated with this operation must 

-- be of a sufficient duration to allow its linked operation to be correctly correlated. 

PlayAnnouncementArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

informationToSend [0] InformationToSend {bound}, 

disconnectFromlPForbidden [1] BOOLEAN DEFAULT TRUE, 

requestAnnouncementCompleteNotif ication [2] BOOLEAN DEFAULT TRUE, 
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extensions [3] 

callSegmentID [5] 

reque st Announcement St art edNotif icat ion 



Extensions {bound} 
CallSegmentID {bound} 
[51] BOOLEAN DEFAULT FALSE, 



OPTIONAL, 
OPTIONAL, 



promptAndCollectUserlnformation { PARAMETERS - BOUND : bound} OPERATION 



ARGUMENT 

RESULT 

ERRORS 



{ bound } 



Prompt AndCol lee tUserlnformationArg 

ReceivedlnformationArg {bound} 

{canceled | 

improperCallerResponse | 

missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unavailableResource | 

unexpectedDataValue | 

unexpectedParameter | 

unknownCSID} 
LINKED { specializedResourceReport } 

CODE opcode -prompt AndCol lee tUser Information} 

Direction: gsmSCF -> gsmSRF, Timer: T pc 
This operation is used to interact with a user to collect information. 



PromptAndCollectUserlnformationArg { PARAMETERS - BOUND : bound} 



SEQUENCE { 



collectedlnfo 

disconnectFromlPForbidden 

informationToSend 

extensions 

callSegmentID 



[0] 
[1] 
[2] 
[3] 
[4] 



request Announcement St art edNotif icat ion 



Collectedlnfo, 
BOOLEAN DEFAULT TRUE, 
InformationToSend {bound} 
Extensions {bound} 
CallSegmentID {bound} 
[51] BOOLEAN DEFAULT FALSE, 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



ReceivedlnformationArg { PARAMETERS - BOUND : bound} ::= CHOICE { 
digitsResponse [0] Digits {bound} 



specializedResourceReport OPERATION ::= { 

ARGUMENT SpecializedResourceReportArg 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode- specializedResourceReport } 

-- Direction: gsmSRF -> gsmSCF, Timer: T srr 

-- This operation is used as the response to a PlayAnnouncement operation when the announcement 
-- completed report indication is set. 



SpecializedResourceReportArg : 
allAnnouncementsComplete 
fir st Announcement Started 



CHOICE { 



[50] NULL, 
[51] NULL 



END 



The following value ranges apply for operation specific timers in CAP: 



short: 

medium: 

long: 



1 s- 10 s 
1 s - 60 s 
1 s - 30 minutes 



Table 6-2 lists all operation timers and the value range for each timer. The definitive value for each operation timer may 
be network specific and has to be defined by the network operator. 

Table 6-2: Operation timers and their value range 



Operation Name 


Timer 


Value range 


PlayAnnouncement 


T pa 


Long 


PromptAndCollectUserlnformation 


T pc 


Long 


SpecializedResourceReport 


Tsrr 


Short 
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6.2.2 gsmSRF/gsmSCF contracts, packages and ACs 
6.2.2.1 gsmSRF/gsmSCF ASN.1 modules 

CAP-gsmSCF-gsmSRF-pkgs-contracts-acs {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-gsmSCF-gsmSRF-pkgs-contracts-acs (104) version5(4)} 

DEFINITIONS :: = BEGIN 

-- This module specifies the Operation Packages, Contracts, Application Contexts 
-- and Abstract Syntaxes used for the gsmSRF - gsmSCF interface, for the control of 
-- circuit switched calls. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

PARAMETERS - BOUND , 

cAPSpecif icBoundSet 
FROM CAP-classes classes 

-- Elements that exist in cAPSpecif icBoundSet in Rel-5 are not changed in Rel-6. As a 
-- result, the value range of data type definitions in Rel-5 are not changed in Rel-6. 

CONTRACT, 

OPERATION- PACKAGE , 
OPERATION 
FROM Remote -Operations -Information- Objects ros-InformationObjects 

TCMessage { } 
FROM TCAPMessages tc-Messages 

APPLICATION- CONTEXT, 
dialogue -abstract -syntax 
FROM TC-Notation-Extensions tc-NotationExtensions 

playAnnouncement { } , 

promptAndCollectUserlnformation { } , 

specializedResourceReport 
FROM CAP-gsmSCF-gsmSRF-ops-args gsmSCF-gsmSRF-Operations- - Object Identifier ' gsmSCF-gsmSRF- 
Operations' is updated to version5{4) in Rel-6. As 

-- a result, the present module, ' CAP-gsmSCF-gsmSRF-pkgs-contracts-acs ' , IMPORTS CAP 
-- Operation definitions from CAP-gsmSCF-gsmSRF-ops-args version5(4) . Operation 
-- definitions are used in the ABSTRACT SYNTAX definitions and in the OPERATION PACKAGE 
-- definitions. 

activityTest , 

cancel { } , 

assistRequestlnstructions { } 
FROM CAP-gsmSSF-gsmSCF-ops-args gsmSSF-gsmSCF-Operations 

-- Object Identifier ' gsmSSF-gsmSCF-Operations ' is updated to version5(4) in Rel-6. AS 
-- a result, the present module, ' CAP-gsmSCF-gsmSRF-pkgs-contracts-acs ' , IMPORTS CAP 
-- Operation definitions from CAP-gsmSSF-gsmSCF-ops-args version5(4) . Operation 
-- definitions are used in the ABSTRACT SYNTAX definitions and in the OPERATION PACKAGE 
-- definitions. 

gsmSRF-scf ActivationOf AssistPackage { } 
FROM CAP-gsmSSF-gsmSCF-pkgs- contract s-acs gsmSSF-gsmSCF- Protocol 

-- Object Identifier ' gsmSSF-gsmSCF-Protocol ' is updated to version5(4) in Rel-6. As a 
-- result, the present module, ' CAP-gsmSCF-gsmSRF-pkgs-contracts-acs ' , IMPORTS CAP Operation 
-- Package definitions from CAP-gsmSSF-gsmSCF-pkgs-contracts-acs version5(4) . Operation 
-- Package definitions are used in the CONTRACT definitions. 

id-package- spec ializedResourceControl, 
id-package-activityTest , 
id-package -gsmSRF-scf Cancel, 
-- The OPERATION- PACKAGE Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

id-ac-gsmSRF-gsmSCF, 
-- The APPLICATION-CONTEXT Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

id-contract-gsmSRF-gsmSCF, 
-- The CONTRACT Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

id-as-basic-gsmSRF-gsmSCF, 
-- The ABSTRACT- SYNTAX Identifiers for CAP V4 in Rel-6 are the same as for CAP V4 in Rel-5. 

classes, 

ros- Inf ormationOb j ects , 

tc-Messages, 

tc-NotationExtensions , 
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gsmSCF-gsmSRF-Operations , 

gsmSSF-gsmSCF-Operations , 
-- Object Identifiers gsmSSF-gsmSCF-Operations and gsmSCF-gsmSRF-Operations are updated 
-- to version5(4) in Rel-S. As a result, the present module, ' CAP-gsmSCF-gsmSRF-pkgs- 
-- contracts-acs ' , IMPORTS Rel-6 versions of the CAP Operation definitions. 

gsmSSF-gsmSCF- Protocol 
-- Object Identifier gsmSSF-gsmSCF-Protocol is updated to version5(4) in Rel-6. As a result, 
-- the present module IMPORTS Rel-6 versions of the CAP Operation Package definitions. 

FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules(3) cap-object-identifiers (100) version5 (4) } ; 

-- Application Contexts 

-- CAP V4 Rel-5 and CAP V4 Rel-6 use the same Application Context version. The CONTRACT 
-- and ABSTRACT SYNTAXES for the call control related Application Contexts, however, are 
-- defined in Rel-6. This is needed to use parameter definitions that are defined in Rel-6. 

-- Refer to ITU-T Recommendation Q.775 for the formal definition of APPLICATION-CONTEXT. 

-- The structured DIALOGUE MODE is defined in ITU-T Recommendation Q.771; the 

-- dialogue-abstract-syntax ABSTRACT SYNTAX is defined in ITU-T Recommendation Q.775. 

gsmSRF-gsmSCF-ac APPLICATION-CONTEXT ::= { 

CONTRACT gsmSRF-gsmSCF-contract 

DIALOGUE MODE structured 

TERMINATION basic 

ABSTRACT SYNTAXES {dialogue-abstract- syntax | 

gsmSRF-gsmSCF- abstract -syntax} 

APPLICATION CONTEXT NAME id-ac-gsmSRF-gsmSCF } 
-- ' gsmSRF-gsmSCF-contract ' and ' gsmSRF-gsmSCF-abstract-syntax 1 are defined in the present 
-- module. 

-- Contracts 

-- The CONTRACT definitions are updated for Rel-6, due to the fact that the individual 

-- OPERATION- PACKAGE definitions are updated in Rel-6. 

gsmSRF-gsmSCF-contract CONTRACT ::= { 

INITIATOR CONSUMER OF (gsmSRF- scf ActivationOf AssistPackage {cAPSpecif icBoundSet } } 
RESPONDER CONSUMER OF { specializedResourceControlPackage {cAPSpecif icBoundSet} | 

activityTestPackage | 

gsmSRF-scf CancelPackage {cAPSpecif icBoundSet } } 
ID id-contract-gsmSRF-gsmSCF} 

-- The OPERATION- PACKAGES are defined in the present module, except for 
-- gsmSRF- scf ActivationOf AssistPackage, which is defined in CAP-gsmSSF-gsmSCF-pkgs-contracts-acs . 

-- Operation Packages 

-- The OPERATION- PACKAGE definitions are updated for Rel-6, due to the fact that the individual 

-- OPERATION definitions are updated in Rel-6. The OPERATION definitions are IMPORTED from 

-- CAP-gsmSSF-gsmSCF-ops-args and from CAP-gsmSCF-gsmSRF-ops-args . 

specializedResourceControlPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {playAnnouncement {bound} | 

promptAndCollectUserlnformation {bound} } 
SUPPLIER INVOKES { specializedResourceReport } 
ID id-package- spec ializedResourceControl} 

gsmSRF- scf CancelPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {cancel {bound}} 
ID id-package-gsmSRF-scf Cancel} 

activityTestPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { activityTest } 
ID id-package-activityTest } 

-- Abstract Syntaxes 

-- GsmSRFgsmSCFInvokable and GsmSRFgsmSCFReturnable use OPERATION definitions with 

-- version5{4). As a result, BASIC-gsmSRF-gsmSCF-PDUs uses version5{4) OPERATION definitions. 

-- As a subsequent result, gsmSRF-gsmSCF-abstract-syntax uses version5(4) OPERATION 

-- definitions. That ABSTRACT- SYNTAX is used in the gsmSRF-gsmSCF-ac APPLICATION-CONTEXT 

-- definition (CAP from gsmSRF to gsmSCF) . 

gsmSRF-gsmSCF-abstract-syntax ABSTRACT- SYNTAX ::= { 

BASIC-gsmSRF-gsmSCF-PDUs 

IDENTIFIED BY id-as-basic-gsmSRF-gsmSCF } 
-- 'BASIC-gsmSRF-gsmSCF-PDUs' is defined in the present module. 

BASIC-gsmSRF-gsmSCF-PDUs ::= TCMessage {(GsmSRFgsmSCFInvokable}, 

{GsmSRFgsmSCFReturnable} } 
-- 'GsmSRFgsmSCFInvokable' and 'GsmSRFgsmSCFReturnable' are defined in the present module. 

GsmSRFgsmSCFInvokable OPERATION : : = { 
activityTest | 

assistRequestlnstructions {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
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playAnnouncement {cAPSpecif icBoundSet } | 
promptAndCollectUserlnformation {cAPSpecif icBoundSet} | 
specializedResourceReport 

-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args . 

GsmSRFgsmSCFReturnable OPERATION : : = { 
activityTest | 

assistRequestlnstructions {cAPSpecif icBoundSet } | 
cancel {cAPSpecif icBoundSet } | 
playAnnouncement {cAPSpecif icBoundSet } | 
promptAndCollectUserlnformation {cAPSpecif icBoundSet } 

-- The OPERATION definitions are IMPORTED from CAP-gsmSSF-gsmSCF-ops-args and from 
-- CAP-gsmSCF-gsmSRF-ops-args. 



SMS Control 



This clause defines the protocol used for CAMEL control of MO SMS and MT SMS. CAMEL control of MO SMS uses 
version 3 of the application context, and CAMEL control of MT SMS uses version 4 of the application context. 

7.1 SMS operations and arguments 

CAP-SMS-ops-args {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) umts- network (1) 
modules ( 3 ) cap-SMS-ops-args (105) version5{4)} 

-- The module CAP-SMS-ops-args is updated to version5(4) for Rel-6. The OPERATION definitions 
-- are not modified. 

DEFINITIONS IMPLICIT TAGS : : = BEGIN 

-- This module contains the operations and operation arguments used for the 
-- smsSSF- gsmSCF interface, for the control of MO-SMS and MT-SMS. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

errortypes, 

datatypes, 

operationcodes , 

classes, 

ros- Inf ormationOb j ects , 

tc-Messages 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

OPERATION 
FROM Remote -Operations -Information- Objects ros- Inf ormationOb j ects 

ServiceKey 
FROM CSl-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) inDomain(l) in-network (1) 
modules(O) csl-datatypes (2) versionl(O)} 

MiscCalllnfo 
FROM CS2-datatypes {itu-t(O) identif ied-organization (4) etsi(0) inDomain(l) in-network (1) 
cs2(20) modules (0) in-cs2-datatypes (0) versionl(O)} 

IMEI, 

IMSI, 

ISDN-AddressString 
FROM MAP-CommonDataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-CommonDataTypes (18) version9(9)} 

GPRSMSClass, 

Locationlnformation, 

MS-Classmark2 
FROM MAP-MS-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-MS-DataTypes (11) version9(9)} 

PARAMETERS - BOUND 
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FROM CAP-classes classes 

opcode -connectSMS , 

opcode-continueSMS , 

opcode - eventReportSMS , 

opcode- furnishCharginglnformationSMS, 

opcode- initialDPSMS, 

opcode-releaseSMS , 

opcode - requestReportSMSEvent , 

opcode -resetTimerSMS 
FROM CAP-operationcodes operationcodes 
-- The CAP Operation identifiers for CAP V3 and CAP V4 for SMS in Rel-6 are the same as in Rel-5. 

CalledPartyBCDNumber { } , 

EventSpecif iclnf ormationSMS , 

EventTypeSMS , 

Extensions { } , 

FCISMSBillingChargingCharacteristics, 

Locationlnf ormationGPRS , 

RPCause, 

SMS-AddressString, 

SMSEvent, 

TimeAndTimezone { } , 

TimerlD, 

TimerValue, 

TPDataCodingScheme , 

TPProtocol Identifier, 

TPShortMessageSpecif iclnf o, 

TPValidityPeriod 
FROM CAP-datatypes datatypes 

-- For Rel-6, the CAP-datatypes module is updated to version5 (4) ; Object Identifier 'datatypes' 
-- is also updated to version5(4) . As a result, the present module uses Rel-6 data type definitions. 

missingCustomerRecord, 

missingParameter, 

parameterOutOf Range , 

systemFailure, 

taskRefused, 

unexpectedComponentSequence , 

unexpectedDataValue , 

unexpectedParameter 
FROM CAP-errortypes errortypes 

-- For Rel-6, the CAP-errortypes module is updated to version5 (4) ; Object Identifier 
-- 'errortypes' is also updated to version5(4) . As a result, the present module uses Rel-6 
-- error type definitions. 

CallRef erenceNumber 
FROM MAP-CH-DataTypes {itu-t{0) identif ied-organization (4 ) etsi{0) mobileDomain (0) 
gsm-Network (1) modules(3) map-CH-DataTypes (13) version9(9)} 



connectSMS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT ConnectSMSArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter} 
CODE opcode-connectSMS} 

Direction: gsmSCF -> gsmSSF or gprsSSF, Timer: T consms 

This operation is used to request the smsSSF to perform the SMS processing 
actions to route or forward a short message to a specified destination. 

ConnectSMSArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

callingPartysNumber [0] SMS-AddressString OPTIONAL, 

destinationSubscriberNumber [1] CalledPartyBCDNumber {bound} OPTIONAL, 

sMSCAddress [2] ISDN-AddressString OPTIONAL, 

extensions [10] Extensions {bound} OPTIONAL, 



continueSMS OPERATION ::= 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 
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CODE opcode-continueSMS} 

-- Direction: gsmSCF -> smsSSF, Timer: T cuesms 

-- This operation is used to request the smsSSF to proceed with 
-- Short Message processing at the DP at which it previously suspended 
-- Short Message processing to await gsmSCF instructions (i.e. proceed 
--to the next Point in Association in the SMS FSM) . The smsSSF 
-- continues SMS processing without substituting new data from the gsmSCF. 

eventReportSMS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT EventReportSMSArg {bound} 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 

CODE opcode-eventReportSMS} 

Direction: gsmSSF or gprsSSF -> gsmSCF, Timer: T erbsms 

This operation is used to notify the gsmSCF of a Short Message related event (FSM events 
such as submission, delivery or failure) previously requested by the gsmSCF in a 
RequestReportSMSEvent operation. 



EventReportSMSArg { PARAMETERS - BOUND 
eventTypeSMS 

event Spec if icInformationSMS 
miscCalllnf o 



extensions 



bound} ::= SEQUENCE { 
[0] EventTypeSMS, 
[1] EventSpecif icInformationSMS 



OPTIONAL, 



[2] MiscCalllnfo DEFAULT {messageType request}, 

[10] Extensions {bound} OPTIONAL, 



furnishCharginglnformationSMS { PARAMETERS - BOUND : bound} OPERATION 
ARGUMENT FurnishCharginglnf ormationSMSArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter} 
CODE opcode- furnishCharginglnformationSMS} 

Direction: gsmSCF — > gsmSSF or gprsSSF, Timer: Tf c: [ sms 
This operation is used to request the smsSSF to generate, 
or to include some information in the default SM record, 
intended for off line charging of the Short Message. 



register a charging record 
The registered charging record is 



Furni shCharginglnf ormat ionSMSArg { PARAMETERS - BOUND 
FCISMSBillingChargingCharacteristics {bound} 

initialDPSMS { PARAMETERS - BOUND : bound} OPERATION : 



ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



Direction: gsmSSF or gprsSSF - 
This operation is used after a 



InitialDPSMSArg {bound} 
FALSE 

{missingCustomerRecord | 
missingParameter | 
parameterOutOfRange | 
systemFailure | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter} 
opcode- initialDPSMS} 

gsmSCF, Timer: 



bound} 



idpsms 



TDP to indicate request for service. 



InitialDPSMSArg { PARAMETERS - BOUND : bound} 

serviceKey [0 

destinationSubscriberNumber [1 

callingPartyNumber [2 

eventTypeSMS [3 

iMSI [4 

locationlnformationMSC [5 

locationlnformationGPRS [6 

sMSCAddress [7 

timeAndTimezone [8 

tPShortMessageSpecif iclnfo [9 
tPProtocol Identifier 
tPDataCodingScheme 
tPValidityPeriod 
extensions 



: = SEQUENCE { 

ServiceKey, 

CalledPartyBCDNumber {bound} 

SMS-AddressString 

EventTypeSMS 

IMSI 

Locationlnf ormat ion 

LocationlnformationGPRS 

ISDN-AddressString 

TimeAndTimezone {bound} 

TPShortMessageSpecif iclnfo 
[10] TPProtocolIdentif ier 
[11] TPDataCodingScheme 
[12] TPValidityPeriod 
[13] Extensions {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



smsRef erenceNumber 

mscAddress 

sgsn-Number 



[14] CallRef erenceNumber 
[15] ISDN-AddressString 
[16] ISDN-AddressString 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
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ms-Classmark2 [17] MS-Classmark2 OPTIONAL, 

gPRSMSClass [18] GPRSMSClass OPTIONAL, 

iMEI [19] IMEI OPTIONAL, 

calledPartyNumber [20] ISDN-AddressString OPTIONAL 
} 

The UserCSGInformation is conveyed in the Locationlnformation for CS and LocationlnformationGPRS 
for GPRS. The encoding of the parameter is as defined in 3GPP TS 29.002 [11] . 

releaseSMS OPERATION ::= { 

ARGUMENT ReleaseSMSArg 

RETURN RESULT FALSE 

ALWAYS RESPONDS FALSE 

CODE opcode-releaseSMS} 

Direction: gsmSCF -> gsmSSF or gprsSSF, Timer: T relsms 

This operation is used to prevent an attempt to submit or deliver a short message. 

ReleaseSMSArg ; : = RPCause 

requestReportSMSEvent { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT RequestReportSMSEventArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter} 
CODE opcode-requestReportSMSEvent} 

Direction: gsmSCF -> gsmSSF or gprsSSF, Timer: T rrbsms 

This operation is used to request the gsmSSF or gprsSSF to monitor for a 

Short Message related event (FSM events such as submission, delivery or failure) 

and to send a notification to the gsmSCF when the event is detected. 

RequestReportSMSEventArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

sMSEvents [0] SEQUENCE SIZE (1 .. bound . knumOf SMSEvents) OF SMSEvent , 

extensions [10] Extensions {bound} OPTIONAL, 

}" 

Indicates the Short Message related events (s) for notification. 

resetTimerSMS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT ResetTimerSMSArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter} 
CODE opcode-resetTimerSMS} 

-- Direction: gsmSCF -> smsSSF, Timer: T r tsms 

-- This operation is used to request the smsSSF to refresh an application 
-- timer in the smsSSF. 

ResetTimerSMSArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

timerlD [0] TimerlD DEFAULT tssf, 

timervalue [1] TimerValue, 

extensions [2] Extensions {bound} OPTIONAL, 



END 



7.1.1 Operation timers 

The following value ranges apply for operation specific timers in CAP: 

short: 1 to 20 seconds; 

medium: 1 to 60 seconds; 

long: 1 second to 30 minutes. 
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Table 7-1 lists all operation timers and the value range for each timer. The definitive value for each operation timer may 
be network specific and has to be defined by the network operator. 

Table 7-1 : Operation timers and their value range 



Operation Name 


Timer 


Value range 


ConnectSMS 


Tconsms 


Short 


ContinueSMS 


T cuesms 


Short 


EventReportSMS 


Terbsms 


Short 


FurnishCharginglnformationSMS 


Tfcisms 


Short 


InitialDPSMS 


T idpsms 


Short 


ReleaseSMS 


Trelsms 


Short 


RequestReportSMSEvent 


Trrbsms 


Short 


ResetTimerSMS 


Trtsms 


Short 



7.2 SMS contracts, packages and ACs 
7.2.1 smsSSF/gsmSCFASN.1 module 

CAP-smsSSF-gsmSCF-pkgs-contracts-acs {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules(3) cap-smsSSF-gsmSCF-pkgs-contracts-acs (106) version5(4)} 

DEFINITIONS ::= BEGIN 

-- This module specifies the Operation Packages, Contracts, Application Contexts 
-- and Abstract Syntaxes used for the smsSSF - gsmSCF interface, for the 
-- control of MO-SMS and MT-SMS. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

PARAMETERS - BOUND , 

cAPSpecif icBoundSet 
FROM CAP-classes classes 

-- Elements that exist in cAPSpecif icBoundSet in Rel-5 are not changed in Rel-6. As a 
-- result, the value range of data type definitions in Rel-5 are not changed in Rel-6. 

CONTRACT , 

OPERATION- PACKAGE , 
OPERATION 
FROM Remote -Operations -Information- Objects ros-Inf ormationObjects 

TCMessage { } 
FROM TCAPMessages tc-Messages 

APPLICATION- CONTEXT, 
dialogue -abstract -syntax 
FROM TC-Notation-Extensions tc-NotationExtensions 

connectSMS{ } , 

continueSMS, 

eventReportSMS { } , 

furnishChargingInformationSMS{ } , 

initialDPSMS{ } , 

releaseSMS, 

requestReportSMSEvent { } , 

resetTimerSMS { } 
FROM CAP-SMS-ops-args sms-Operations 

-- Object Identifier 'sms-Operations' is updated to version5(4) in Rel-6. As a result, 
-- the present module, ' CAP-smsSSF-gsmSCF-pkgs-contracts-acs ' , IMPORTS CAP Operation 
-- definitions from CAP-SMS-ops-args version5(4) . Operation definitions are used in the 
-- ABSTRACT SYNTAX definitions and in the OPERATION PACKAGE definitions. 

id-ac-cap3- sms -AC , 
id-ac-cap4- sms -AC , 
-- The APPLICATION-CONTEXT Identifiers for CAP V3 and CAP V4 for SMS in Rel-6 are the same as 
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-- in Rel-5. 

id-cap3SmsSsf TogsmScf , 
id-cap4SmsSsf TogsmScf , 
-- The CONTRACT Identifiers for CAP V3 and CAP V4 for SMS in Rel-6 are the same as in Rel-5. 

id-package -smsActivat ion, 

id-package- smsConnect, 

id-package- smsContinue , 

id-package -smsRe lease, 

id-package -smsEventHandling, 

id-package -smsBil ling, 

id-package -smsTimer, 
-- The OPERATION- PACKAGE Identifiers for CAP V3 and CAP V4 for SMS in Rel-6 are the same as 
--in Rel-5 . 

sms-Operations , 
-- Object Identifier sms-Operations is updated to version5(4) in Rel-6. As a result, the present 
-- module, ' CAP-smsSSF-gsmSCF-pkgs-contracts-acs ' , IMPORTS Rel-6 versions of the CAP Operation 
-- definitions. 

tc-NotationExtensions , 

tc-Messages, 

ros- Inf ormationOb j ects , 

classes, 

id-as-smsSSF-gsmSCF-AS 
-- The ABSTRACT- SYNTAX Identifiers for CAP V3 and CAP V4 for SMS in Rel-6 are the same as 
--in Rel-5 . 

FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 



Application Contexts 



Rel-6 uses the same Application Context versions for SMS as Rel-5. 
SYNTAXES for SMS are defined in Rel-6. 



The CONTRACT and ABSTRACT 



Refer to ITU-T Recommendation Q.775 for the formal definition of APPLICATION-CONTEXT. 
The structured DIALOGUE MODE is defined in ITU-T Recommendation Q.771; the 
dialogue-abstract-syntax ABSTRACT SYNTAX is defined in ITU-T Recommendation Q.775. 



cap3-sms-AC APPLICATION-CONTEXT 



CONTRACT 
DIALOGUE MODE 
ABSTRACT SYNTAXES 



{ 



cap3SMS 

structured 

{dialogue-abstract-syntax | 

sms- Abstract Syntax} 

id-ac-cap3-sms-AC} 
This application context shall be used for CAMEL support of MO-SMS. 
'cap3SMS' and ' sms-AbstractSyntax 1 are defined in the present module. 



APPLICATION CONTEXT NAME 



cap4-sms-AC APPLICATION-CONTEXT 



{ 



CONTRACT 
DIALOGUE MODE 
ABSTRACT SYNTAXES 



cap4SMS 

structured 

{dialogue-abstract-syntax | 

sms -Abstract Syntax} 

id-ac-cap4- sms -AC } 
This application context shall be used for CAMEL support of MT-SMS. 
'cap4SMS' and ' sms-AbstractSyntax 1 are defined in the present module. 



APPLICATION CONTEXT NAME 



Contracts 

The CONTRACT definitions for SMS in Rel- 

defined in Rel-6. 



6 use OPERATION- PACKAGE definitions which are 



cap 3 SMS CONTRACT ::= { 

-- dialogue initiated by gprsSSF or gsmSSF with InitialDPSMS Operation 



INITIATOR CONSUMER OF 
RES PONDER CONSUMER OF 



ID 



smsActivationPackage {cAPSpecif icBoundSet } } 
smsConnectPackage {cAPSpecif icBoundSet} | 
smsReleasePackage | 

smsEventHandlingPackage {cAPSpecif icBoundSet 
smsTimerPackage {cAPSpecif icBoundSet } J 
smsBillingPackage {cAPSpecif icBoundSet } | 
smsProcessingPackage } 
id-cap3SmsSsf TogsmScf } 



} I 



The OPERATION- PACKAGES are defined in the present module. 
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cap4SMS CONTRACT ::= { 

-- dialogue initiated by gprsSSF or gsmSSF with InitialDPSMS Operation 

INITIATOR CONSUMER OF {smsActivationPackage {cAPSpecif icBoundSet } } 
RESPONDER CONSUMER OF {smsConnectPackage {cAPSpecif icBoundSet } | 

smsReleasePackage | 

smsEventHandlingPackage {cAPSpecif icBoundSet } | 
smsTimerPackage {cAPSpecif icBoundSet } | 
smsBillingPackage {cAPSpecif icBoundSet } | 
smsProcessingPackage } 
ID id-cap4SmsSsfTogsmScf } 

-- The OPERATION- PACKAGES are defined in the present module. 

-- Operation Packages 

-- The OPERATION- PACKAGE definitions for SMS in Rel-6 use Operation definitions from Rel-6. The 

-- OPERATION definitions are IMPORTED from CAP-SMS-ops-args . 

smsActivationPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { initialDPSMS {bound}} 
ID id-package-smsActivation} 

smsConnectPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {connectSMS {bound}} 
ID id-package- smsConnect} 

smsProcessingPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { continueSMS } 
ID id-package-smsContinue} 

smsReleasePackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {releaseSMS} 
ID id-package-smsRelease} 

smsEventHandlingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {requestReportSMSEvent {bound}} 
SUPPLIER INVOKES {eventReportSMS {bound}} 
ID id-package-smsEventHandling} 

smsBillingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { f urnishCharginglnf ormationSMS {bound}} 
ID id-package-smsBilling} 

smsTimerPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { resetTimerSMS {bound}} 
ID id-package-smsTimer} 

-- Abstract Syntaxes 

-- Smslnvokable and SmsReturnable use OPERATION definitions with version5{4) . As a result, 

-- Generic-sms-PDUs uses version5(4) OPERATION definitions. As a subsequent result, 

-- sms-AbstractSyntax uses version5(4) OPERATION definitions. That ABSTRACT- SYNTAX is used 

-- in the cap3-sms-AC APPLICATION-CONTEXT definition and in the and cap4-sms-AC APPLICATION- 

-- CONTEXT definition (CAP from smsSSF to gsmSCF) . 

sms-AbstractSyntax ABSTRACT- SYNTAX ::= { 

Generic - sms - PDUs 

IDENTIFIED BY id-as- smsSSF-gsmSCF-AS } 
-- 'Generic-sms-PDUs' is defined in the present module. 

Generic-sms-PDUs ::= TCMessage {{Smslnvokable}, 

{ SmsReturnable } } 
-- 'Smslnvokable' and 'SmsReturnable' are defined in the present module. 

Smslnvokable OPERATION ::= { 

connectSMS {cAPSpecif icBoundSet } | 

eventReportSMS {cAPSpecif icBoundSet } | 

f urnishCharginglnf ormationSMS {cAPSpecif icBoundSet } | 

initialDPSMS {cAPSpecif icBoundSet } | 

requestReportSMSEvent {cAPSpecif icBoundSet } | 

resetTimerSMS {cAPSpecif icBoundSet } } 
-- The OPERATION definitions are IMPORTED from CAP-SMS-ops-args version5(4). 

SmsReturnable OPERATION : : = { 

connectSMS {cAPSpecif icBoundSet } | 

continueSMS | 

f urnishCharginglnf ormationSMS {cAPSpecif icBoundSet } | 

initialDPSMS {cAPSpecif icBoundSet } | 
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releaseSMS | 

requestReportSMSEvent {cAPSpecif icBoundSet } | 
resetTimerSMS {cAPSpecif icBoundSet} } 
-- The OPERATION definitions are IMPORTED from CAP-SMS-ops-args version5(4). 



8 GPRS Control 

8.1 gsmSCF/gprsSSF operations and arguments 

CAP-gprsSSF-gsmSCF-ops-args {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules(3) cap-GPRS-ops-args (107) version5{4)} 

-- Module CAP-gprsSSF-gsmSCF-ops-args is updated to version5(4) for Rel-6. The OPERATION 
-- definitions in this module are not modified, compared to Rel-5. 

DEFINITIONS IMPLICIT TAGS ::= BEGIN 

-- This module contains the operations and operation arguments used for the 
-- gprsSSF - gsmSCF interface, for the control of GPRS. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

errortypes, 

datatypes, 

operationcodes , 

classes, 

ros-InformationObjects 
FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 

OPERATION 
FROM Remote -Operations -Information- Objects ros-InformationObjects 

ServiceKey 
FROM CSl-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) inDomain(l) in-network (1) 
modules(O) csl-datatypes (2) versionl(O)} 

MiscCalllnfo 
FROM CS2-datatypes {itu-t(O) identif ied-organization (4) etsi(0) inDomain(l) in-network (1) 
cs2(20) modules (0) in-cs2-datatypes (0) versionl(O)} 

IMEI, 

IMSI, 

ISDN-AddressString 
FROM MAP-CommonDataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-CommonDataTypes (18) version9(9)} 

GPRSChargingID, 

GPRSMSClass, 

GSN-Address, 

RAIdentity 
FROM MAP-MS-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(0) mobileDomain (0) 
gsm-Network (1) modules(3) map-MS-DataTypes (11) version9(9)} 

PARAMETERS - BOUND 
FROM CAP-classes classes 

opcode-activityTestGPRS, 
opcode - applyChargingGPRS , 
opcode - applyChargingReportGPRS , 
opcode-cancelGPRS , 
opcode-connectGPRS , 
opcode-continueGPRS , 
opcode-entityReleasedGPRS , 
opcode-eventReportGPRS , 
opcode- furnishCharginglnformationGPRS, 
opcode- initialDPGPRS, 
opcode-releaseGPRS , 
opcode-requestReportGPRSEvent , 
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opcode-resetTimerGPRS , 

opcode -sendCharginglnf ormationGPRS 
FROM CAP-operationcodes operationcodes 

-- The CAP Operation identifiers for CAP V3 for GPRS in Rel-6 are the same as the CAP Operation 
-- identifiers for CAP V3 for GPRS in Rel-5. 

AccessPointName { } , 

GPRSCause { } , 

ChargingCharacteristics , 

ChargingResult , 

ChargingRollOver, 

EndUs e r Addr e s s , 

Extensions, 

FCIGPRSBillingChargingCharacteristics, 

GPRSEventSpecif iclnformation { } , 

GPRSEvent, 

GPRSEventType , 

Locationlnf ormationGPRS , 

PDPID, 

PDPInitiationType , 

QualityOf Service , 

SCIGPRSBillingChargingCharacteristics { } , 

SGSNCapabilities , 

TimeAndTimezone { } , 

TimerlD, 

TimerValue 
FROM CAP-datatypes datatypes 

-- For Rel-6, the CAP-datatypes module is updated to version5 (4) ; Object Identifier 'datatypes' 
-- is also updated to version5(4) . As a result, the present module uses Rel-6 data type definitions. 

missingCustomerRecord, 

missingParameter, 

parameterOutOf Range , 

systemFailure, 

taskRefused, 

unexpectedComponentSequence , 

unexpectedDataValue , 

unexpectedParameter, 

unknownPDPID 
FROM CAP-errortypes errortypes 

-- For Rel-6, the CAP-errortypes module is updated to version5 (4) ; Object Identifier 
-- 'errortypes' is also updated to version5(4) . As a result, the present module uses Rel-6 
-- error type definitions. 



activityTestGPRS OPERATION ::= { 

RETURN RESULT TRUE 

CODE opcode-activityTestGPRS} 

-- Direction: gsmSCF -> gprsSSF, Timer: T at 

-- This operation is used to check for the continued existence of a relationship between the gsmSCF 
-- and gprsSSF. If the relationship is still in existence, then the gprsSSF will respond. If no 
-- reply is received, then the gsmSCF will assume that the gprsSSF has failed in some way 
-- and will take the appropriate action. 

applyChargingGPRS OPERATION : : = { 

ARGUMENT ApplyChargingGPRSArg 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

unexpectedComponentSequence | 

unexpectedParameter | 

unexpectedDataValue | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unknownPDPID} 
CODE opcode-applyChargingGPRS} 

-- Direction gsmSCF -> gprsSSF, Timer T a 

-- This operation is used for interacting from the gsmSCF with the gprsSSF CSE-controlled 
-- GPRS session or PDP Context charging mechanism. 

ApplyChargingGPRSArg ; : = SEQUENCE { 

ChargingCharacteristics [0] ChargingCharacteristics, 

tariffSwitchlnterval [1] INTEGER (1.. 86400) OPTIONAL, 

pDPID [2] PDPID OPTIONAL, 

}" 
-- tariffSwitchlnterval is measured in 1 second units. 
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ChargingResult , 


[1] 


QualityOf Service 


[2] 


BOOLEAN DEFAULT TRUE 


[3] 


PDPID 



3GPP TS 29.078 version 8.2.1 Release 8 93 ETSI TS 129 078 V8.2.1 (2010-04) 



applyChargingReportGPRS OPERATION ; : = { 

ARGUMENT ApplyChargingReportGPRSArg 

RETURN RESULT TRUE 

ERRORS {missingParameter | 

unexpectedComponentSequence | 

unexpectedParameter | 

unexpectedDataValue | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unknownPDPID} 
CODE opcode-applyChargingReportGPRS} 

Direction gprsSSF -> gsmSCF, Timer T ac 

The ApplyChargingReportGPRS operation provides the feedback from the gprsSCF to the gsmSCF 
CSE-controlled GPRS session charging mechanism. 

ApplyChargingReportGPRSArg 
ChargingResult 

qualityOfService [1] QualityOf Service OPTIONAL, 

active 

pDPID [3] PDPID OPTIONAL, 

chargingRollOver [4] ChargingRollOver OPTIONAL 

} 

cancelGPRS OPERATION ::= { 

ARGUMENT CancelGPRSArg 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

taskRefused | 

unknownPDPID} 
CODE opcode-cancelGPRS} 

Direction: gsmSCF -> gprsSSF, Timer: T cag 
This generic operation cancels all previous requests, 
i.e. all EDPs and reports can be cancelled by the gsmSCF. 

CancelGPRSArg ::= SEQUENCE { 

pDPID [0] PDPID OPTIONAL, 



connectGPRS { PARAMETERS - BOUND : bound} OPERATION: := { 
ARGUMENT ConnectGPRSArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange | 
unknownPDPID | 
systemFailure | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter} 
CODE opcode -connectGPRS} 

-- Direction: gsmSCF -> gprsSSF, Timer: T con q 
-- This operation is used to modify the Access Point Name used when establishing a PDP Context. 

ConnectGPRSArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 
accessPointName [0] AccessPointName {bound}, 
pdpID [1] PDPID OPTIONAL, 



continueGPRS OPERATION ::= { 

ARGUMENT ContinueGPRSArg 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

unknownPDPID | 

unexpectedDataValue } 
CODE opcode -continueGPRS} 

Direction: gsmSCF -> gprsSSF, Timer: T cu 

This operation is used to request the gprsSSF to proceed with processing at the DP at 
which it previously suspended processing to await gsmSCF instructions (i.e., proceed to 
the next point in processing in the Attach/Detach state model or PDP Context 
state model) substituting new data from the gsmSCF. 
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ContinueGPRSArg :: = SEQUENCE { 

pDPID [0] PDPID OPTIONAL, 



entityReleasedGPRS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT EntityReleasedGPRSArg {bound} 
RETURN RESULT TRUE 
ERRORS {missingParameter | 

taskRefused | 
unknownPDPID} 
CODE opcode-entityReleasedGPRS} 

Direction: gprsSSF -> gsmSCF, Timer: T e 

This operation is used when the GPRS Session is detached or a PDP Context is diconnected and 

the associated event is not armed for reporting. 

The usage of this operation is independent of the functional entity that initiates the Detach 

or PDP Context Disconnection and is independent of the cause of the Detach or PDP Context 

Disconnect. 

EntityReleasedGPRSArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 
gPRSCause [0] GPRSCause {bound}, 

pDPID [1] PDPID OPTIONAL, 



eventReportGPRS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT EventReportGPRSArg {bound} 
RETURN RESULT TRUE 
ERRORS {unknownPDPID} 

CODE opcode -eventReportGPRS} 

Direction gprsSSF -> gsmSCF, Timer T er 

This operation is used to notify the gsmSCF of a GPRS session or PDP context related 
events (e.g. PDP context activation) previously requested by the gsmSCF in a 
RequestReportGPRSEventoperation . 

EventReportGPRSArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 
gPRSEventType [0] GPRSEventType, 

miscGPRSInfo [1] MiscCalllnfo DEFAULT {messageType request}, 

gPRSEventSpecif iclnformation [2] GPRSEventSpecif iclnformation {bound} OPTIONAL, 
pDPID [3] PDPID OPTIONAL, 



furnishCharginglnformationGPRS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT FurnishCharginglnf ormationGPRSArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter | 
unknownPDPID} 
CODE opcode- furnishCharginglnformationGPRS} 

-- Direction: gsmSCF -> gprsSSF, Timer: Tfcig 

-- This operation is used to request the gprsSSF to generate, register a logical record or to 
-- include some information in the default logical GPRS record. 

-- The registered logical record is intended for off line charging of the GPRS session 
--or PDP Context. 

FurnishCharginglnformationGPRSArg { PARAMETERS - BOUND : bound} ::= 
FCIGPRSBillingChargingCharacteristics {bound} 

initialDPGPRS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT InitialDPGPRSArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingCustomerRecord | 

missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter} 
CODE opcode- initialDPGPRS} 

Direction gprsSSF -> gsmSCF, Timer T id 

This operation is used by the gprsSSF when a trigger is detected at a DP in the GPRS state 
machines to request instructions from the gsmSCF 
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InitialDPGPRSArg { PARAMETERS - BOUND 
serviceKey 
gPRSEventType 
mSISDN 
iMSI 

timeAndTimeZone 
gPRSMSClass 
endUserAddress 
qualityOf Service 
accessPointName 
routeingArealdentity 
chargingID 
sGSNCapabilities 
locationlnformationGPRS 
pDPInitiationType 
extensions 



bound 
[0 
[1 
[2 
[3 
[4 
[5 
[6 
[7 
[8 
[9 



[12] 



: = SEQUENCE { 

ServiceKey, 

GPRSEventType , 

ISDN-AddressString, 

IMSI, 

TimeAndTimezone {bound} 

GPRSMSClass 

EndUserAddress {bound} 

QualityOf Service 

AccessPointName {bound} 

RAIdentity 
[10] GPRSChargingID 
[11] SGSNCapabilities 
LocationlnformationGPRS 
[13] PDPInitiationType 
[14] Extensions {bound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 

OPTIONAL, 



gGSNAddress 
secondaryPDP- context 
iMEI 



[15] GSN-Address 
[16] NULL 
[17] IMEI 



OPTIONAL, 
OPTIONAL, 
OPTIONAL 



The RouteingArealdentity parameter is not used. 

The receiving entity shall ignore RouteingArealdentity if received. 
The RouteingArealdentity is conveyed in the LocationlnformationGPRS parameter. 
The CSGInformation is conveyed in the LocationlnformationGPRS parameter. The encoding of the 
-- parameter is as defined in 3GPP TS 29.002 [11] . 

releaseGPRS { PARAMETERS - BOUND : bound} OPERATION ::= { 



ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



ReleaseGPRSArg {bound} 
FALSE 

{missingParameter | 
taskRefused | 
unknownPDPID} 
opcode-releaseGPRS } 



Direction: gsmSCF -> gprsSSF, Timer: T 

This operation is used to tear down an existing GPRS session or PDP Context at any phase. 



ReleaseGPRSArg { PARAMETERS - BOUND 
gprsCause 
pDPID 



bound} ::= SEQUENCE { 

[0] GPRSCause {bound} 
[1] PDPID 



OPTIONAL, 



requestReportGPRSEvent { PARAMETERS - BOUND : bound} OPERATION 



{ 



ARGUMENT RequestReportGPRSEventArg {bound} 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

parameterOutOfRange | 

systemFailure | 

taskRefused | 

unexpectedComponentSequence | 

unexpectedDataValue | 

unexpectedParameter | 

unknownPDPID} 
CODE opcode - requestReportGPRSEvent } 

Direction: gsmSCF -> gprsSSF, Timer: T r e 

This operation is used to request the gprsSSF to monitor for an event (e.g., GPRS events 
such as attach or PDP Context activiation) , then send a notification back to the 
gsmSCF when the event is detected. 



RequestReportGPRSEventArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

gPRSEvent [0] SEQUENCE SIZE (1 . .bound . knumOf GPRSEvents) OF GPRSEvent, 

pDPID [1] PDPID OPTIONAL, 



Indicates the GPRS related events for notification. 



resetTimerGPRS OPERATION 



{ 



ARGUMENT ResetTimerGPRSArg 

RETURN RESULT FALSE 

ERRORS {missingParameter | 

parameterOutOfRange | 
taskRefused | 

unexpectedComponentSequence | 
unexpectedDataValue | 
unexpectedParameter | 
unknownPDPID} 
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CODE opcode-resetTimerGPRS} 

Direction: gsmSCF -> gprsSSF, Timer: T rtg 

This operation is used to request the gprsSSF to refresh an application timer in the gprsSSF. 

ResetTimerGPRSArg ; ; = SEQUENCE { 

timerlD [0] TimerlD DEFAULT tssf, 

timervalue [1] TimerValue, 



sendCharginglnformationGPRS { PARAMETERS - BOUND : bound} OPERATION ::= { 
ARGUMENT SendCharginglnf ormationGPRSArg { bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

unexpectedComponentSequence | 
unexpectedParameter | 
parameterOutOfRange | 
systemFailure | 
taskRefused | 
unexpectedDataValue | 
unknownPDPID} 
CODE opcode -sendCharginglnformationGPRS} 

-- Direction: gsmSCF -> gprsSSF, Timer: T sc -j_ q 

-- This operation is used to instruct the gprsSSF on the charging information which the 
-- gprsSSF shall send to the Mobile Station by means of GSM access signalling. 

SendCharginglnformationGPRSArg { PARAMETERS - BOUND : bound} ::= SEQUENCE { 

sCIGPRSBillingChargingCharacteristics [0] SCIGPRSBillingChargingCharacteristics {bound} 



8.1 .1 GPRS Reference Number 

CAP-GPRS-Ref erenceNumber {itu-t{0) identif ied-organization (4) etsi{0) mobileDomain (0) 
umt s- network (1) modules(3) cap-dialoguelnf ormation (111) version5(4)} 

-- Module CAP-GPRS-Ref erenceNumber is updated to version5(4) for Rel-6. The definitions 
-- in this module are not modified, compared to Rel-5. 

DEFINITIONS ::= BEGIN 

EXPORTS 

id- CAP-GPRS-Ref erenceNumber, 

CAP - GPRS - Re f erenceNumber- Abstract -Syntax ; 

IMPORTS 

Integer4 
FROM CSl-DataTypes {itu-t(O) identif ied-organization (4 ) etsi{0) inDomain(l) in-network (1) 
modules(O) csl-datatypes (2) versionl(O)} 

id-CAP-GPRS-ReferenceNumber OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(0) 
mobileDomain (0) umt s- network (1) as(l) cap-GPRS-Ref erenceNumber (5) version3{2)} 

cAP-GPRS-ReferenceNumber-Abstract-Syntax ABSTRACT- SYNTAX ::= {CAP-GPRS-Ref erenceNumber IDENTIFIED BY 
id-CAP-GPRS-ReferenceNumber} 

CAP-GPRS-Ref erenceNumber ::= SEQUENCE { 

destinationReference [0] Integer4 OPTIONAL, 

originationRef erence [1] Integer4 OPTIONAL 

} 

This parameter is used to identify the relationship between SGSN and the gsmSCF. 

END --of CAP-GPRS-Ref erenceNumber 

8.1.2 Operation timers 

The following value ranges apply for operation specific timers in CAP: 

short: 1 to 20 seconds; 

medium: 1 to 60 seconds; 

long: 1 second to 30 minutes 
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Table 8-1 lists all operation timers and the value range for each timer. The definitive value for each operation timer may 
be network specific and has to be defined by the network operator. 

Table 8-1 : Operation timers and their value range 



Operation Name 


Timer 


value 


ActivityTestGPRST 


T atg 


Short 


ApplyChargingGPRS 


T acg 


Short 


ApplyChargingReportGPRS 


T acrg 


Short 


CancelGPRS 


T cag 


Short 


ConnectGPRS 


T cong 


Short 


ContinueGPRS 


T cueg 


Short 


EntityReleasedGPRS 


T erg 


Short 


EventReportGPRS 


T ereg 


Short 


FurnishCharginglnformationGPRS 


T fcig 


Short 


InitialDPGPRS 


T idpg 


Short 


ReleaseGPRS 


T rg 


Short 


RequestReportGPRSEvent 


T rrqe 


Short 


ResetTimerGPRS 


T rtg 


Short 


SendCharginglnformationGPRS 


T scig 


Short 



8.2 gsmSCF/gprsSSF contracts, packages and ACs 
8.2.1 gprsSSF/gsmSCFASN.1 module 

CAP-gprsSSF-gsmSCF-pkgs-contracts-acs {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-gprsSSF-gsmSCF-pkgs-contracts-acs (108) version5(4)} 
DEFINITIONS : : = BEGIN 

-- This module specifies the Operation Packages, Contracts, Application Contexts 
-- and Abstract Syntaxes used for the gprsSSF - gsmSCF interface, for the 
-- control of GPRS. 

-- The table in subclause 2.1 lists the specifications that contain the modules 
-- that are used by CAP. 

IMPORTS 

PARAMETERS - BOUND , 

cAPSpecif icBoundSet 
FROM CAP-classes classes 

-- Elements that exist in cAPSpecif icBoundSet in Rel-5 are not changed in Rel-6. As a 
-- result, the value range of data type definitions in Rel-5 are not changed in Rel-6. 

CONTRACT , 

OPERATION- PACKAGE , 
OPERATION 
FROM Remote -Operations -Information- Objects ros-Inf ormationObjects 

TCMessage { } 
FROM TCAPMes sages tc -Messages 

APPLICATION- CONTEXT, 
dialogue -abstract -syntax 
FROM TC-Notation-Extensions tc-NotationExtensions 

activityTestGPRS , 
applyChargingGPRS , 
applyChargingReportGPRS , 
cancelGPRS, 
connectGPRS { } , 
ContinueGPRS, 
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entityReleasedGPRS { } , 
furnishCharginglnf ormationGPRS { } , 
initialDPGPRS {}, 
releaseGPRS { } , 
eventReportGPRS { } , 
requestReportGPRSEvent { } , 
resetTimerGPRS , 

sendCharginglnformationGPRS { } 
FROM CAP-gprsSSF-gsmSCF-ops-args gprsSSF-gsmSCF-Operations 

id-ac-CAP-gprsSSF-gsmSCF-AC, 

id-ac-CAP-gsmSCF-gprsSSF-AC, 
-- The APPLICATION-CONTEXT Object Identifiers for CAP V3 for GPRS in Rel-6 are the same as for 
-- CAP V3 for GPRS in Rel-5. 

id-capGprsSsf TogsmScf , 
id-capGsmScf ToGprsSsf , 
-- The CONTRACT Object Identifiers for CAP V3 for GPRS are updated in Rel-6. 

id-as-gprsSSF-gsmSCF-AS, 
id-as-gsmSCF-gprsSSF-AS, 
-- The ABSTRACT- SYNTAX Object Identifiers for CAP V3 for GPRS are updated in Rel-6. 

id-package -gprsScf Activation, 
id-package-gprsConnect , 
id-package -gprsContinue, 
id-package-gprsRelease , 
id-package -gprsEventHandling, 
id-package -gprsExceptionlnformat ion, 
id-package -gprsTimer, 
id-package -gprsBil ling, 
id-package -gprsCharging, 
id-package-gprsChargeAdvice, 
id-package-gprsActivityTest , 
id-package-gprsCancel , 
-- The OPERATION- PACKAGE Object Identifiers for CAP V3 for GPRS are updated in Rel-6. 

classes, 

ros- Inf ormationOb j ects , 

tc-Messages, 

tc-NotationExtensions , 

gprsSSF-gsmSCF- Operations 
-- Object Identifier ' gprsSSF-gsmSCF-Operations ' is updated for Rel-6. 

FROM CAP-object-identif iers {itu-t(O) identif ied-organization (4) etsi(0) mobileDomain (0) 
umt s- network (1) modules (3) cap-object-identifiers (100) version5(4)} 



-- Application Contexts 

-- The APPLICATION-CONTEXT definitions for CAP V3 for GPRS are updated in Rel-6. 

-- However, the APPLICATION-CONTEXT definitions for CAP V3 for GPRS in Rel-6 use the same 

-- Object Identifier for APPLICATION CONTEXT NAME as CAP V3 for GPRS in Rel-5. 

-- Refer to ITU-T Recommendation Q.775 for the formal definition of APPLICATION-CONTEXT. 

-- The structured DIALOGUE MODE is defined in ITU-T Recommendation Q.771; the 

-- dialogue-abstract-syntax ABSTRACT SYNTAX is defined in ITU-T Recommendation Q.775. 

cap-gprssf-scfAC APPLICATION-CONTEXT ::= { 

CONTRACT capGprsSsfToScf 

DIALOGUE MODE structured 

ABSTRACT SYNTAXES {dialogue-abstract- syntax | 

gprsSSF-gsmSCFAbs tract Syntax} 

APPLICATION CONTEXT NAME id-ac-CAP-gprsSSF-gsmSCF-AC } 
-- ' capGprsSsfToScf ' and ' gprsSSF-gsmSCFAbstractSyntax 1 are defined in the present 
-- module. 

cap-gsmscf-gprsssfAC APPLICATION-CONTEXT ::= { 

CONTRACT capGsmScfToGprsSsf 

DIALOGUE MODE structured 

ABSTRACT SYNTAXES {dialogue-abstract- syntax | 

gsmSCF-gprsSSFAbs tract Syntax} 

APPLICATION CONTEXT NAME id-ac-CAP-gsmSCF-gprsSSF-AC } 
-- 'capGsmScfToGprsSsf' and ' gsmSCF-gprsSSFAbstractSyntax' are defined in the present 
-- module. 
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-- Contracts 

-- The CONTRACT definitions for CAP V3 for GPRS are updated in Rel-6. 

capGprsSsfToScf CONTRACT ::= { 

-- dialogue initiated by gprsSSF with InitialDPGPRS, ApplyChargingReportGPRS, 

-- EntityReleasedGPRS and EventReportGPRS Operations 



INITIATOR CONSUMER OF 



RES PONDER CONSUMER OF 



ID 



{gprsScfActivationPackage {cAPSpecif icBoundSet } | 

gprsEventHandlingPackage {cAPSpecif icBoundSet} | 

gprsChargingPackage | 

gprsExceptionlnformationPackage {cAPSpecif icBoundSet } 

{gprsConnectPackage {cAPSpecif icBoundSet } | 

gprsProcessingPackage | 

gprsReleasePackage {cAPSpecif icBoundSet } | 

gprsEventHandlingPackage {cAPSpecif icBoundSet } | 

gprsTimerPackage | 

gprsBillingPackage {cAPSpecif icBoundSet } | 

gprsChargingPackage | 

gprsCancelPackage | 

gprsChargeAdvicePackage {cAPSpecif icBoundSet } } 

id-capGprsSsf TogsmScf } 



-- The OPERATION- PACKAGES are defined in the present module. 

capGsmScfToGprsSsf CONTRACT ::= { 

-- dialogue initiated by gsmSCF with ApplyChargingGPRS, ActivityTestGPRS, 

-- CancelGPRS, FurnishCharginglnformationGPRS, ReleaseGPRS, 

-- RequestReportGPRSEvent and SendCharginglnformationGPRS Operations 

INITIATOR CONSUMER OF {gprsReleasePackage {cAPSpecif icBoundSet } | 

gprsEventHandlingPackage {cAPSpecif icBoundSet } 

gprsBillingPackage {cAPSpecif icBoundSet } | 

gprsChargingPackage | 

gprsActivityTestPackage | 

gprsCancelPackage | 

gprsChargeAdvicePackage {cAPSpecif icBoundSet } } 
ID id-capGsmScfToGprsSsf } 

-- The OPERATION- PACKAGES are defined in the present module. 

-- Operation Packages 

-- The OPERATION- PACKAGE definitions for CAP V3 for GPRS are updated in Rel-6. 

gprsScfActivationPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { initialDPGPRS {bound}} 
ID id-package-gprsScf Activation} 

gprsConnectPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {connectGPRS {bound}} 
ID id-package-gprsConnect } 

gprsProcessingPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { continueGPRS } 
ID id-package-gprsContinue} 

gprsReleasePackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {releaseGPRS {bound}} 
ID id-package-gprsRelease} 

gprsEventHandlingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { requestReportGPRSEvent {bound}} 
SUPPLIER INVOKES {eventReportGPRS {bound}} 
ID id-package-gprsEventHandling} 

gprsExceptionlnformationPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE :: 
CONSUMER INVOKES { entityReleasedGPRS {bound}} 
ID id-package -gprsExceptionlnformat ion} 

gprsTimerPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { resetTimerGPRS } 
ID id-package-gprsTimer} 

gprsBillingPackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { f urnishCharginglnf ormationGPRS {bound}} 
ID id-package-gprsBilling} 

gprsChargingPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {applyChargingGPRS} 
SUPPLIER INVOKES {applyChargingReportGPRS} 
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ID id-package-gprsCharging} 

gprsChargeAdvicePackage { PARAMETERS - BOUND : bound} OPERATION- PACKAGE ::= { 
CONSUMER INVOKES { sendCharginglnf ormationGPRS {bound}} 
ID id-package-gprsChargeAdvice} 

gprsActivityTestPackage OPERATION- PACKAGE : := { 
CONSUMER INVOKES { activityTestGPRS } 
ID id-package-gprsActivityTest } 

gprsCancelPackage OPERATION- PACKAGE ::= { 
CONSUMER INVOKES {cancelGPRS } 
ID id-package-gprsCancel} 

-- Abstract Syntaxes 

-- The ABSTRACT- SYNTAX definitions for CAP V3 for GPRS are updated in Rel-6. 

gprsSSF-gsmSCFAbstractSyntax ABSTRACT- SYNTAX ::= { 

GenericGprsSSF-gsmSCF-PDUs 

IDENTIFIED BY id-as-gprsSSF-gsmSCF-AS } 
-- ' GenericGprsSSF-gsmSCF-PDUs ' is defined in the present module. 

GenericGprsSSF-gsmSCF-PDUs ::= TCMessage { {GprsSsfToGsmScf Invokable} , 

{GprsSsfToGsmScf Returnable} } 
-- ' GprsSsfToGsmScf Invokable ' and ' GprsSsfToGsmScf Returnable ' are defined in the present module. 

GprsSsfToGsmScf Invokable OPERATION ::= { 
activityTestGPRS | 
applyChargingGPRS | 
applyChargingReportGPRS | 
cancelGPRS | 

connectGPRS {cAPSpecif icBoundSet} | 
entityReleasedGPRS {cAPSpecif icBoundSet} | 
eventReportGPRS {cAPSpecif icBoundSet} | 
furnishCharginglnf ormationGPRS {cAPSpecif icBoundSet } | 
initialDPGPRS {cAPSpecif icBoundSet } | 
releaseGPRS {cAPSpecif icBoundSet} | 
requestReportGPRSEvent {cAPSpecif icBoundSet } | 
resetTimerGPRS | 
sendCharginglnf ormationGPRS {cAPSpecif icBoundSet } } 

GprsSsfToGsmScf Returnable OPERATION ::= { 
activityTestGPRS | 
applyChargingGPRS | 
applyChargingReportGPRS | 
cancelGPRS | 

connectGPRS {cAPSpecif icBoundSet } | 
continueGPRS | 

entityReleasedGPRS {cAPSpecif icBoundSet } | 
furnishCharginglnf ormationGPRS {cAPSpecif icBoundSet } 
initialDPGPRS {cAPSpecif icBoundSet } | 
releaseGPRS {cAPSpecif icBoundSet} | 
requestReportGPRSEvent {cAPSpecif icBoundSet } | 
resetTimerGPRS | 
sendCharginglnf ormationGPRS {cAPSpecif icBoundSet } } 

gsmSCF-gprsSSFAbstractSyntax ABSTRACT- SYNTAX ::= { 

GenericGsmSCF-gprsSSF-PDUs 

IDENTIFIED BY id-as-gsmSCF-gprsSSF-AS } 
-- ' GenericGsmSCF-gprsSSF-PDUs ' is defined in the present module. 

GenericGsmSCF-gprsSSF-PDUs ::= TCMessage { {GsmScfToGprsSsf Invokable} , 

{GsmScfToGprsSsfReturnable} } 
-- ' GsmScfToGprsSsf Invokable ' and 1 GsmScfToGprsSsfReturnable' are defined in the present module. 

GsmScfToGprsSsf Invokable OPERATION ::= { 
activityTestGPRS | 
applyChargingGPRS | 
cancelGPRS | 

furnishCharginglnf ormationGPRS {cAPSpecif icBoundSet } | 
releaseGPRS {cAPSpecif icBoundSet} | 
requestReportGPRSEvent {cAPSpecif icBoundSet } | 
sendCharginglnf ormationGPRS {cAPSpecif icBoundSet } } 

GsmScfToGprsSsfReturnable OPERATION ::= { 
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activityTestGPRS | 

applyChargingGPRS | 

cancelGPRS | 

furnishCharginglnf ormationGPRS {cAPSpecif icBoundSet } | 

releaseGPRS {cAPSpecif icBoundSet} | 

requestReportGPRSEvent {cAPSpecif icBoundSet } | 

sendCharginglnf ormationGPRS {cAPSpecif icBoundSet } } 



Application Entity procedures 



The description of the application entity procedures for CAMEL Phase 3 can be found in 3GPP TS 23.078 [7]. 



10 Error procedures 



The present clause specifies the generic error procedures for CAP. The error procedure descriptions are divided in two 
subclauses, subclause 10.1 listing the errors related to CAP Operations and subclause 10.2 listing the errors related to 
error conditions in the different FEs which are not directly related to the CAP Operations. 

The gsmSSF FSM states, smsSSF FSM states and gprsSSF FSM states which are referred to in the present clause are 
described in 3GPP TS 23.078 [7]. The CAP Operations Play Announcement, PromptAndCollectUserlnformation and 
SpecializedResourceReport refer to states in the gsmSRF SRSM which are described in ETSI ETS 300 374-1 [24] as 
well as to states in 3GPP TS 23.078 [7]. 

10.1 Operation related error procedures 

The following subclauses specify the generic error handling for the CAP Operation related errors. The errors are 
defined as Operation Errors in clauses 6, 7 and 8. Errors which have a specific procedure for a CAP Operation are 
described in clause 1 1 with the detailed procedure of the related CAP Operation. 

The TC services which are used for reporting CAP Operation Errors are described in subclause 14.1. All Errors which 
can be detected by the ASN. 1 decoder, already may have been detected during the decoding of the TC message and 
indicated by the TC error indication "MistypedParameter" in the TC-U-Reject. 

10.1.1 Canceled 

10.1.1.1 General Description 



10.1.1.1.1 



Error description 



The gsmSRF uses this Error to indicate" to the gsmSCF that the cancellation of a specific CAP Operation, as requested 
by the gsmSCF, has been successful. The only CAP Operations which may be cancelled are Play Announcement and 
PromptAndCollectUserlnformation. 

10.1.1.2 Operations gsmSCF^gsmSRF 

Procedures at responding entity (gsmSRF) 

A) Receiving Cancel 



Precondition: SRSM FSM state 
Postcondition: SRSM FSM state 



"User Interaction". 
"User Interaction". 



If execution of the indicated CAP Operation has not yet started, then the indicated CAP Operation shall be removed 
from the buffer. If execution of the indicated CAP Operation is in progress, then the execution of that CAP Operation 
shall be terminated. If the indicated CAP Operation was already executed, then then this causes a failure 
("CancelFailed"). 
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B) Sending Error "Canceled" 

Precondition: SRSM FSM state "User Interaction". 

Postcondition: SRSM FSM state "User Interaction". 

After returning the Error "Canceled", the gsmSRF FSM remains in the same state. The execution of the indicated 
Play Announcement or PromptAndCollectUserlnformation CAP Operation is aborted. The gsmSRF shall remain 
connected and the next Play Announcement or PromptAndCollectUserlnformation CAP Operation, if available, shall be 
executed. 

10.1.2 CancelFailed 

1 0.1 .2.1 General description 
10.1.2.1.1 Error description 

The gsmSRF uses this Error to indicate to the gsmSCF that the cancellation of a specific CAP Operation, as requested 
by the gsmSCF, was not successful. Possible failure reasons are: 

"unknownOperation", when the InvokelD of the CAP Operation to cancel is not known to the gsmSRF (this may 
also happen when the CAP Operation has already been completed); 

1 "tooLate", when the invokelD is known but the execution of the CAP Operation is in a state in which it cannot 
be canceled anymore. For instance the announcement is finished but the SpecializedResourceReport has not 
been sent to the gsmSCF yet. The conditions for the occurrence of failure reason "tooLate" are implementation 
dependent; 

2 "operationNotCancellable", when the invokelD points to a CAP Operation that the gsmSCF is not allowed to 
cancel. 

10.1.2.2 Operations gsmSCF^gsmSRF 

Procedures at responding entity (gsmSRF) 

A) Receiving Cancel. However, the indicated CAP Operation is not known, or has already been executed or may not be 
cancelled. This causes a failure, "CancelFailed". 

Precondition: SRSM FSM state "User Interaction". 

Postcondition: SRSM FSM state "User Interaction" or 
SRSM FSM state "Idle". 

B) Sending Error "CancelFailed" 

Precondition: SRSM FSM state "User Interaction" or 
SRSM FSM state "Idle". 

Postcondition: SRSM FSM state "User Interaction" or 
SRSM FSM state "Idle". 

After returning the Error "CancelFailed" the gsmSRF FSM remains in the same state. 

10.1.3 ETCFailed 

1 0.1 .3.1 General description 

10.1.3.1.1 Error description 

The gsmSSF uses this Error to indicate to the gsmSCF that the establishment of a temporary connection to an assisting 
gsmSSF or gsmSRF was not successful (e.g., receiving a "Backwards Release" after sending an ISUP IAM). 
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10.1.3.2 Operations gsmSCF^gsmSSF 

Procedures at responding entity (gsmSSF) 

A gsmSSF receives EstablishTemporaryConnection from a gsmSCF but the establishment of the connection fails, 
which results in returning the Error "ETCFailed" to the gsmSCF. 

Precondition: gsmSSF FSM state "Waiting_for_Instructions". 

Postcondition: gsmSSF FSM state "Waiting_for_Instructions". 

No further error treatment. 

10.1.4 ImproperCallerResponse 

1 0.1 .4.1 General description 
10.1.4.1.1 Error description 

The gsmSRF uses this Error to indicate to the gsmSCF that the format of the user input has been checked by the 
gsmSRF, but does not correspond to the required format as it was defined in the initiating CAP Operation. 

10.1.4.2 Operations gsmSCF^gsmSRF 

Procedures at responding entity (gsmSRF) 

A) gsmSRF receives PromptAndCollectUserlnformation 

Precondition: SRSM FSM state "Connected"; or 

SRSM FSM state "User Interaction". 

Postcondition: SRSM FSM state "User Interaction". 

B) format of the user input is not correct, gsmSRF returns ImproperCallerResponse to gsmSCF 
Precondition: SRSM FSM state "User Interaction". 

Postcondition: SRSM FSM state "User Interaction". 

The gsmSRF shall wait for a new CAP Operation from the gsmSCF. This may be a new 
PromptAndCollectUserlnformation or a Play Announcement. 

10.1.5 MissingCustomerRecord 

1 0.1 .5.1 General description 
10.1.5.1.1 Error description 

The gsmSCF uses this Error to indicate to the gsmSSF, gprsSSF, smsSSF or gsmSRF, that the SLP could not be found 
in the gsmSCF, because the required customer record does not exist, or the requested SLPI, indicated by the 
correlationID in "AssistRequestlnstructions" does not exist anymore. 

10.1.5.2 Operations gsmSSF^gsmSCF 

Procedures at invoking entity (gsmSSF) 

A) Sending CAP Operation 

Precondition: gsmSSF FSM state "Trigger processing" or 

gsmSSF FSM state "Waiting_for_Instructions"; in the assisting gsmSSF case. 
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Postcondition: gsmSSF FSM state "Waiting_for_Instructions". 

gsmSSF FSM state "Waiting_for_Instructions"; in the assisting gsmSSF case. 

B) gsmSSF receives Error "MissingCustomerRecord" 

Precondition: gsmSSF FSM state "Waiting_for_Instructions" or 

gsmSSF FSM state "Waiting_for_Instructions"; in the assisting gsmSSF case. 

Postcondition: gsmSSF FSM state "Idle" or 

gsmSSF FSM state "Idle"; in the assisting gsmSSF case. 

The GMSC or VMSC shall handle the call in accordance with the Default Call Handling parameter of the valid CSI. 

10.1.5.3 Operations gsmSRF^gsmSCF 

Procedures at invoking entity (gsmSRF) 

A) Sending CAP Operation 

Precondition: SRSM FSM state "Connected". 
Postcondition: SRSM FSM state "Connected". 

B) gsmSRF receives Error "MissingCustomerRecord" 
Precondition: SRSM FSM state "Connected". 
Postcondition: SRSM FSM state "Idle". 

The gsmSRF shall initiate a Disconnect. 

1 0.1 .5.4 Operations smsSSF^gsmSCF 

Procedures at invoking entity (smsSSF) 

A) Sending CAP Operation 

Precondition: smsSSF FSM state "Waiting_for_Instructions". 

Postcondition: smsSSF FSM state "Waiting_for_Instructions". 

B) smsSSF receives Error "MissingCustomerRecord" 
Precondition: smsSSF FSM state "Waiting_for_Instructions". 
Postcondition: smsSSF FSM state "Idle". 



The VMSC or SGSN shall handle the Short Message in accordance with the Default SMS Handling parameter of the 
valid CSI. 

1 0.1 .5.5 Operations gprsSSF->gsmSCF 

Procedures at invoking entity (gprsSSF) 

A) Sending CAP Operation 

Precondition: gprsSSF FSM state "Waiting_for_Instructions". 

Postcondition: gprsSSF FSM state "Waiting_for_Instructions". 

B) gprsSSF receives Error "MissingCustomerRecord" 
Precondition: gprsSSF FSM state "Waiting_for_Instructions". 
Postcondition: gprsSSF FSM state "Idle". 
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The SGSN shall handle the GPRS Session or PDP Context in accordance with the Default GPRS Handling parameter of 
the valid CSI. 

10.1.6 MissingParameter 

1 0.1 .6.1 General description 
10.1.6.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this Error to indicate that there is an error in the received 
CAP Operation argument. The responding entity cannot start the execution of the requested CAP Operation because the 
argument is incorrect: an expected optional parameter which is essential for the application is not included in the CAP 
Operation argument. 

10.1.6.2 Operations gsmSCF^gsmSSF 

Procedures at responding entity (gsmSSF) 

Precondition: (1) gsmSSF FSM appropriate state 

(2) gsmSSF FSMCall associated CAP Operation received, appropriate event occurred 

(3) gsmSSME FSM appropriate state 

(4) gsmSSME FSM Non call associated CAP Operation received, appropriate event 

Postcondition: (1) No gsmSSF FSM transition 

(2) gsmSSME FSM transition to the initial state (i.e., before receiving the erroneous CAP Operation) 

The gsmSSF detects the error in the received CAP Operation. The Error parameter "MissingParameter" is returned to 
inform the gsmSCF of this situation. 

10.1.6.3 Operations gsmSSF^gsmSCF 

Procedures at invoking entity (gsmSSF) 

A) Sending CAP Operation 

Precondition: gsmSSF FSM appropriate state 

Postcondition: gsmSSF FSM appropriate state as result of the transfer of the CAP Operation 

B) gsmSSF receives Error "MissingParameter" 

Precondition: gsmSSF FSM appropriate state as result of the transfer of any of the CAP Operation 

Postcondition: gsmSSF FSM state "Idle" 

After receiving this Error, the gsmSSF FSM shall return to the state "Idle". The GMSC or VMSC shall handle the call 
in accordance with the Default Call Handling parameter , valid for this CAMEL dialogue. In the case of an assisting 
gsmSSF, the temporary connection shall be released by the assisting gsmSSF. 

10.1.6.4 Operations gsmSCF^gsmSRF 

Procedures at responding entity (gsmSRF) 

Precondition: SRSM FSM state "Connected"; or 

SRSM FSM state "User Interaction". 

Postcondition: SRSM FSM state "User Interaction". 

The SRSM detects that a required parameter is not present in the CAP Operation argument. The Error parameter 
"MissingParameter" is returned to inform the gsmSCF of this situation. 
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10.1.6.5 Operations gsmSRF^gsmSCF 

Procedures at invoking entity (gsmSRF) 

A) Sending CAP Operation 

Precondition: SRSM FSM state "Connected". 

Postcondition: SRSM FSM state "Connected". 

B) Receiving Error 

Precondition: SRSM FSM state "Connected". 

Postcondition: SRSM FSM state "Idle". 

The gsmSCF detects the error in the received CAP Operation. The Error parameter "MissingParameter" is used to 
inform the gsmSRF of this situation. The SL and maintenance functions are informed. The gsmSCF might try another 
gsmSRF, route the call or release the call (SL dependent). 

1 0.1 .6.6 Operations smsSSF^gsmSCF 

Procedures at invoking entity (smsSSF) 

A) Sending CAP Operation 

Precondition: smsSSF FSM state "WaitingForlnstructions". 

Postcondition: smsSSF FSM state "WaitingForlnstructions". 

B) Receiving Error 

Precondition: smsSSF FSM state "WaitingForlnstructions". 

Postcondition: smsSSF FSM state "Idle". 

After receiving this error, the smsSSF FSM shall transit to the state "Idle". The SGSN or VMSC shall handle the Short 
Message in accordance with the Default SMS Handling parameter of the valid CSI. 

1 0.1 .6.7 Operations gsmSCF -> smsSSF 

Procedures at responding entity (smsSSF) 
precondition: 

(1) smsSSF appropriate state. 

(2) smsSSF SMS associated CAP Operation received, appropriate event occurred, 
postcondition: 

(1) smsSSF transition to the same state. 

The smsSSF detects the error in the received CAP Operation. The Error parameter "MissingParameter" is returned to 
inform the gsmSCF of this situation. 

1 0.1 .6.8 Operations gprsSSF-^gsmSCF 

Procedures at invoking entity (gprsSSF) 

A) Sending CAP Operation 

Precondition: gprsSSF FSM state "Waiting_for_Instructions". 

Postcondition: gprsSSF FSM state "Waiting_for_Instructions". 
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B) Receiving Error 

Precondition: gprsSSF FSM state "Waiting_for_Instructions". 

Postcondition: gprsSSF FSM state "Idle". 

After receiving this error, the gprsSSF FSM shall transits to the state "Idle". The SGSN shall handle the GPRS Session 
or PDP Context in accordance with the Default GPRS Handling parameter of the valid CSI. 

1 0.1 .6.9 Operations gsmSCF^gprsSSF 

Procedures at responding entity (gprsSSF) 

precondition: 

(1) gprsSSF appropriate state. 

(2) gprsSSF CAP Operation received, appropriate event occurred, 
postcondition: 

(1) gprsSSF transition to the same state. 

The gprsSSF detects the error in the received CAP Operation. The Error parameter "MissingParameter" is returned to 
inform the gsmSCF of this situation. 

10.1.7 ParameterOutOf Range 

1 0.1 .7.1 General description 
10.1.7.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this Error to indicate that it cannot start the execution of the 
requested CAP Operation because an error in a parameter of the CAP Operation argument is detected: a parameter 
value is out of range. 

10.1.7.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.7.3 Operations gsmSSF^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.7.4 Operations gsmSCF-»gsmSRF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .7.5 Operations smsSSF -> gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.7.6 Operations gsmSCF-^smsSSF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .7.7 Operations gprsSSF -^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 
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1 0.1 .7.8 Operations gsmSCF^gprsSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.8 RequestedlnfoError 

1 0.1 .8.1 General description 
10.1.8.1.1 Error description 

The gsmSSF uses this Error to indicate to the gsmSCF that the information requested in the CalllnformationRequest 
CAP Operation is not known to the gsmSSF or is not available. 

10.1.8.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.9 SystemFailure 

1 0.1 .9.1 General description 
10.1.9.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this error to indicate that it is not able to execute a specific 
task as requested by a CAP Operation, and recovery is not expected to be completed within the current call instance. 

10.1.9.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.9.3 Operations gsmSSF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

10.1.9.4 Operations gsmSCF^gsmSRF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

10.1.9.5 Operations gsmSRF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .9.6 Operations smsSSF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

10.1.9.7 Operations gsmSCF^smsSSF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .9.8 Operations gprsSSF -^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 
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1 0.1 .9.9 Operations gsmSCF^gprsSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.10 TaskRefused 

10.1.10.1 General description 
10.1.10.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this Error to indicate that it is not able to execute a specific 
task as requested by a CAP Operation, and recovery is expected to be completed within the current call instance. 

If the gsmSSF requests MoveLeg or SplitLeg operations in the gsmSSF while user interaction is in progress in an 
affected Call Sement, then CAP_Error (task refused) is returned. 

1 0.1 .1 0.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.3 Operations gsmSSF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.4 Operations gsmSCF^gsmSRF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.5 Operations gsmSRF^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.6 Operations smsSSF^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.7 Operations gsmSCF^smsSSF 

SMS Related 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.8 Operations gprsSSF -^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 0.9 Operations gsmSCF^gprsSSF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 
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10.1.11 UnavailableResource 

10.1.11.1 General description 
10.1.11.1.1 Error description 

The gsmSRF uses this Error to indicate to the gsmSCF that it is not able to perform its function (i.e., play a certain 
announcement and/or collect specific user information), and cannot be replaced. A reattempt is not possible. 

1 0.1 .1 1 .2 Operations gsmSCF^gsmSRF 

Procedures at responding entity (gsmSRF) 

A) gsmSRF receiving Play Announcement or PromptAndCollectUserlnformation 

Precondition: SRSM FSM state "Connected"; if initial Play Announcement or 
PromptAndCollectUserlnformation; or 

SRSM FSM state "User Interaction"; if not initial Play Announcement or 
PromptAndCollectUserlnformation. 

B) gsmSRF is not able to perform its function (and cannot be replaced). The gsmSRF sends the Error 
" UnavailableResource" . 

Precondition: SRSM FSM state "User Interaction". 

Postcondition: SRSM FSM state "User Interaction". 

10.1.12 UnexpectedComponentSequence 

10.1.12.1 General description 
10.1.12.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this Error to indicate that it cannot start the execution of the 
requested CAP Operation because a SACF or MACF rule is violated, or the CAP Operation cannot be executed in the 
current state of the FSM. 

1 0.1 .1 2.2 Operations gsmSCF^gsmSSF 

In this case the gsmSSF detects the erroneous situation, sends the Error "UnexpectedComponentSequence" and remains 
in the same state. 

1 0.1 .1 2.3 Operations gsmSSF^gsmSCF 

If the CAP Operation is sent by an "initiating" gsmSSF in the context of an existing relationship, then the gsmSCF 
returns the Error parameter. On receiving the error the gsmSSF FSM shall transit to the state "Idle". The VMSC or 
GMSC shall handle the call in accordance with the Default Call Handling parameter, valid for this CAMEL dialogue. 

1 0.1 .1 2.4 Operations gsmSCF->gsmSRF (applicable for direct gsmSCF-gsmSRF case 
only) 

In this case the gsmSRF detects the erroneous situation, sends the Error "UnexpectedComponentSequence" and remains 
in the same state. 

1 0.1 .1 2.5 Operations gsmSRF^gsmSCF 

In this case, an error occurs if the gsmSRF has already an established relationship with the gsmSCF and sends the CAP 
Operation AssistRequestlnstructions. The gsmSCF detects the erroneous situation, informs SL and maintenance 
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functions and returns the error parameter. On receiving the Error parameter, the gsmSRF FSM shall transit to the state 
"Idle" and releases the temporary connection. 

1 0.1 .1 2.6 Operations smsSSF -*gsmSCF 

If the CAP Operation is sent by the smsSSF in the context of an existing relationship, then the gsmSCF returns the Error 
parameter. On receiving the error, the smsSSF FSM shall transit to the state "Idle". The SGSN or VMSC shall handle 
the Short Message in accordance with the Default SMS Handling parameter of the valid CSI. 

1 0.1 .1 2.7 Operations gsmSCF-^smsSSF 

In this case the smsSSF detects the erroneous situation, sends the Error "UnexpectedComponentSequence" and remains 
in the same state. 

1 0.1 .1 2.8 Operations gprsSSF -^gsmSCF 

If the CAP Operation is sent by the gprsSSF in the context of an existing relationship, then the gsmSCF returns the 
Error parameter. On receiving the error, the gprsSSF FSM shall transit to the state "Idle". The SGSN shall handle the 
GPRS Session or PDP Context in accordance with the Default GPRS Handling parameter of the valid CSI. 

1 0.1 .1 2.9 Operations gsmSCF^gprsSSF 

In this case the gprsSSF detects the erroneous situation, sends the Error "UnexpectedComponentSequence" and remains 
in the same state. 

10.1.13 UnexpectedDataValue 

10.1.13.1 General description 
10.1.13.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this Error to indicate that it cannot execute the requested 
CAP Operation because a parameter has an unexpected data value. 

Note that this error does not overlap with "ParameterOutOfRange". 

EXAMPLE: startTime DateAndTime ::= -- value indicating January 32 1993, 12: 15: 01 

The responding entity does not expect this value and responds with Error "UnexpectedDataValue". 

1 0.1 .1 3.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 3.3 Operations gsmSSF^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 3.4 Operations gsmSCF^gsmSRF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 3.5 Operations gsmSRF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 
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1 0.1 .1 3.6 Operations smsSSF^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 3.7 Operations gsmSCF^smsSSF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 3.8 Operations gprsSSF -^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 3.9 Operations gsmSCF^gprsSSF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

10.1.14 Unexpected Parameter 

10.1.14.1 General description 
10.1.14.1.1 Error description 

The gsmSCF, gsmSSF, gsmSRF, smsSSF or gprsSSF uses this Error to indicate that there is an error in the received 
CAP Operation argument. A valid but unexpected parameter was present in the CAP Operation argument. The presence 
of this parameter is not consistent with the presence of the other parameters. The responding entity cannot start the 
execution of the CAP Operation. 

1 0.1 .1 4.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 4.3 Operations gsmSSF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 4.4 Operations gsmSCF^gsmSRF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 4.5 Operations gsmSRF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 4.6 Operations smsSSF^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 4.7 Operations gsmSCF^smsSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 4.8 Operations gprsSSF -^gsmSCF 

Refer to subclause 10. 1.6 MissingParameter for the appropriate error procedures. 
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1 0.1 .1 4.9 Operations gsmSCF^gprsSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.15 UnknownLegID 

10.1.15.1 General description 
10.1.15.1.1 Error description 

The gsmSSF uses this error to indicate to the gsmSCF that a specific leg, indicated by the LegID parameter value in the 
CAP Operation, is unknown to the gsmSSF. 

1 0.1 .1 5.2 Operations gsmSCF^gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.16 UnknownCSID 

10.1.16.1 General description 
10.1.16.1.1 Error description 

The gsmSSF uses this error to indicate to the gsmSCF that a specific Call Segment, indicated by the callSegmentID 
parameter value in the CAP Operation, is unknown to the gsmSSF. 

1 0.1 .1 6.2 Operations gsmSCF^ gsmSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

10.1.17 UnknownPDPID 

10.1.17.1 General description 
10.1.17.1.1 Error description 

The gsmSCF or gprsSSF uses this error to indicate that a specific PDP Context, indicated by the PDPId parameter value 
in the CAP Operation argument, is unknown to the receiving entity. 

1 0.1 .1 7.2 Operations gprsSSF^gsmSCF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 

1 0.1 .1 7.3 Operations gsmSCF^gprsSSF 

Refer to subclause 10.1.6 MissingParameter for the appropriate error procedures. 



1 0.2 Entity related error procedures 



The following subclauses specify the error handling procedures for the Functional Entity related errors. Since the error 
situations are not originated by the reception of a CAP Operation, the invoking entity is denoted here as the entity at 
which the error situation is detected. The responding entity is the entity which receives the error report. 

The TC services used for reporting errors are described in clause 14. 
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1 0.2.1 Expiration of Tssf 

1 0.2.1 .1 General description 
10.2.1.1.1 Error description 

A timeout has occurred in the gsmSSF, gprsSSF, smsSSF or assisting gsmSSF on the response from the gsmSCF. 

10.2.1.2 Procedures gsmSSF^gsmSCF 

Procedure at the invoking entity (gsmSSF or assisting gsmSSF) 

Timeout occurs in gsmSSF on Tssf. 

Precondition: gsmSSF FSM state "Waiting_for_Instructions"; or 

gsmSSF FSM state "Waiting_for_end_of_User_Interaction"; or 

gsmSSF FSM state "Waiting_for_end_of_Temporary_Connection". 

Postcondition: gsmSSF FSM state "Idle". 

The gsmSSF shall abort the TC dialogue and shall transit to the state "Idle". The GMSC or VMSC shall handle the call 
in accordance with the Default Call Handling parameter, valid for this CAMEL dialogue. For CAMEL dialogues that 
are established as a result of a CSI, the Default Call Handling parameter is obtained from the CSI. For gsmSCF initiated 
CAMEL dialogues, the Default Call Handling parameter shall be 'ReleaseCall'. 

The assisting gsmSSF shall abort the TC dialogue and shall transit to the state "Idle". The assisting gsmSSF shall 
release the temporary connection. 

1 0.2.1 .3 Procedures gprsSSF^gsmSCF 

Procedure at the invoking entity (gprsSSF) 

Timeout occurs in gprsSSF on Tssf. 

Precondition: gprsSSF FSM state "Waiting_for_Instructions". 

Postcondition: gprsSSF FSM state "Idle". 

The gprsSSF shall abort the TC dialogue and and the GPRS dialogue and shall transit to the state "Idle". The SGSN 
shall handle the PDP Context in accordance with the Default GPRS Handling parameter of the valid CSI. 

1 0.2.1 .4 Procedures smsSSF^gsmSCF 

Procedure at the invoking entity (smsSSF) 

Timeout occurs in smsSSF on Tssf. 

Precondition: smsSSF FSM state "Waiting_for_Instructions". 

Postcondition: smsSSF FSM state "Idle". 

The smsSSF shall abort the TC dialogue and shall transit to the state "Idle". The MSC or SGSN shall handle the Short 
Message in accordance with the Default SMS Handling parameter of the valid CSI. 
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10.2.2 Expiration of Tsrf 

10.2.2.1 General Description 
10.2.2.1.1 Error description 

A timeout has occurred in the gsmSRF on the response from the gsmSCF. The procedures for handling this error are 
described in ETSI ETS 300 374-1 [24]. 

10.2.2.2 Procedures description 

The procedures for handling this error are described in ETSI ETS 300 374-1 [24]. 

1 1 Detailed operation procedures for circuit switched 
call control 

NOTE: The detailed operation procedures in the present clause which cross reference the gsmSCF FSMs for the 
pre- and postconditions are for information only. 

NOTE: Where a parameter for a circuit switched call control Operation is marked OPTIONAE in ASN. 1, the 

reader is referred to the conditions for presence for this parameter, specified in the respective Information 
Flow in 3GPP TS 23 .078 [7] . 

11.1 ActivityTest procedure 

11.1.1 General description 

The gsmSCF uses this operation to check for the continued existence of a relationship between the gsmSCF and the 
gsmSSF, between the gsmSCF and the gsmSRF or between the gsmSCF and the assist gsmSSF. If the relationship is 
still in existence, then the receiving entity will respond If the ActivityTest operation timer expires, then the gsmSCF 
will assume that the receiving entity has failed in some way and will take appropriate action. 

11.1.1.1 Parameters 

None. 

1 1 .1 .2 Responding entity (gsmSSF, gsmSRF or assist gsmSSF) 
1 1 .1 .2.1 Normal procedure 

gsmSSF preconditions: 

(1) A relationship exists between the gsmSCF and the gsmSSF. 

(2) The gsmSSME FSM is in the state "Idle Management" or in the state "Non-call Associated Treatment". 
gsmSRF or assist gsmSSF preconditions: 

(1) A relationship exists between the gsmSCF and the gsmSRF or assist gsmSSF. 

(2) The gsmSSME FSM is in the state "Idle Management". 
gsmSSF postconditions: 

(1) The gsmSSME FSM stays in, or transits to the state "Non-call Associated Treatment". 
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(2) If the TC Dialogue ID is active and there is a gsmSSF using the dialogue, then the gsmSSME FSM shall send a 
Return Result "ActivityTest" to the gsmSCF. If there are no other management activities (e.g. Call Gapping), 
then the gsmSSME FSM shall transit to the state "Idle Management". Otherwise, the gsmSSME FSM remains in 
the state "Non-call Associated Treatment". 

If the TC Dialogue ID is not active, then the TC in the gsmSSF will issue a P- Abort. The gsmSSME FSM will in 
that case not receive the "ActivityTest" indication and thus will not be able to reply. 

gsmSRF or assist gsmSSF postconditions: 

(1) The gsmSSME FSM transits to the state "Non-call Associated Treatment". 

(2) If the TC Dialogue ID is active and there is a gsmSRF or assist gsmSSF using the dialogue, then the gsmSSME 
FSM shall send a Return Result "ActivityTest" to the gsmSCF. The gsmSSME FSM then returns to the state 
"Idle Management". 

If the TC Dialogue ID is not active, then the TC in the gsmSRF or assist gsmSSF will issue a P- Abort. The 
gsmSSME FSM will in that case not receive the ActivityTest indication and thus will not be able to reply. 

11.1.2.2 Error handling 

Operation related error handling is not applicable, due to class 3 operation. 

1 1 .2 ApplyCharging procedure 
1 1 .2.1 General description 

The gsmSCF uses this operation for interacting with the gsmSSF function: "CSE control of call duration". The 
ApplyChargingReport operation provides the feedback from the gsmSSF to the gsmSCF. 

The charging scenarios supported by this operation are those given in 3GPP TS 22.078 [3] for "CSE control of call 
duration". 

11.2.1.1 Parameters 

aChBillingChargingCharacteristics: 

This parameter specifies a list of parameters required for "CSE control of call duration": 

The list may contain the following parameters: 

timeDurationCharging: 

This list contains the following parameters: 

maxCallPeriodDuration: 

This parameter specifies the period of time for which a call may progress before an ApplyChargingReport 

shall be sent to the gsmSCF. 

- releaselfdurationExceeded: 

This parameter specifies the action to be taken at the gsmSSF when the duration specified above has been 
reached. 

audiblelndicator: 

This parameter indicates to the gsmSSF that an audible indicator may be played to the served subscriber. 
This audible indicator may either be a predefined sequence of tones or a sequence defined by the 
gsmSCF. This parameter shall consist of either tone or burstlist as described below: 

tone: 

This parameter indicates that a warning tone shall be played when the pre-defined warning tone timer 

expires. 
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burstlist: 

This parameter indicates that a variable sequence of tones shall be played when the gsmSCF-defined 

warning tone timer expires. This parameter may consist of the following parameters: 

warningPeriod: 

This parameter indicates the time, before the Max Call Period Duration timer expires when the 

playing of the burstlist shall start. 

- burst: 

This parameter indicates the number of bursts that form the burstlist. 

- burstlnterval: 

This parameter indicates the time interval between the successive burst in the burstlist. 

tonelnBurst: 

This parameter indicates the number of tones to be played in each burst. 

toneDuration: 

This parameter indicates the time duration that the tone shall be played for. 

tonelnterval: 

This parameter indicates the time interval between successive tones in a burst 

tariffSwitchlnterval (for the CSE control of call duration): 

This parameter indicates the time duration until the next tariff switch for the CSE control of call duration. 
The measurement of the elapsed tariff switch period shall start immediately after successful execution of 
this operation. 

party ToCharge: 

This parameter indicates the party in the call. 

- aChChargingAddress: 

This parameter identifies the call party to which the ApplyCharging operation applies. That is the leg or 
srfConnection. 

This parameter is a choice of one of the following parameters: 

- legID: 

This parameter indicates that the "CSE control of call duration" is associated to the specified leg. 

or 

- srfConnection: 

This parameter indicates that the "CSE control of call duration" is associated to the Temporary Connection or 
to the connection to a gsmSRF. 

1 1 .2.2 Responding entity (gsmSSF) 
11.2.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSCF and the gsmSSF. 

(2) The gsmSSF FSM is in one of the following states: 

"Waiting_for_Instructions"; or 
"Waiting_for_end_of_User_Interaction" ; or 
"Waiting_for_end_of_Temporary_Connection" ; or 
"Monitoring". 
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gsmSSF postconditions: 

(1) No gsmSSF FSM state transition. 

On receipt of this operation, the gsmSSF sets the charging data using the information elements included in the operation 
and acts accordingly. 

If the aChChargingAddress indicates a legID, then: 

The "CSE control of call duration" is associated to the specified leg. If Answer has not already been received on 
the incoming or outgoing connection (leg) to the Call Party, then the gsmSSF shall start monitoring for the 
Answer event upon receipt of the ApplyCharging operation. Upon subsequent detection of the Answer event on 
the outgoing connection charging is started. If the Answer event has occurred on the incoming or outgoing 
connection already when the ApplyCharging operation is received, then charging starts immediately. 

A precautionary started DELTA measurement shall be taken into account when charging is started. 

For a change in the connection configuration of the legs - on CPH - the particular point in time when the new 
connection configuration is established shall be taken as Answer time. 

Upon release of the incoming or outgoing connection to the Call Party any indication of Answer event occurred 
on the incoming or outgoing connection shall be cleared, i.e. set to "Answer event not occurred". 

If the aChChargingAddress indicates a srfConnection, then: 

The "CSE control of call duration" is associated to the Temporary Connection or to the connection to a gsmSRF. 
If Answer has not already been received on the Temporary Connection, then the gsmSSF will start monitoring 
for the Answer event upon receipt of the ApplyCharging operation; or, if the gsmSRF is not yet connected, then 
the gsmSSF will start monitoring for a connection to a gsmSRF. Upon subsequent detection of the Answer event 
on the Temporary Connection or the subsequent connection to a gsmSRF, charging shall be started. If the 
Answer event has been received from a Temporary Connection already or if the gsmSRF is already connected 
when the ApplyCharging operation is received, then charging shall start immediately. 

Upon release of the Temporary Connection any indication of Answer event receipt on the outgoing connection 
shall be cleared i.e. set to "Answer event not received". Upon end of the connection to a gsmSRF, any indication 
of the connection to the gsmSRF shall be cleared. 

11.2.2.2 Error handling 

"TaskRefused": In addition to the generic error handling noted below, this error shall be indicated when: 

a previously received call period duration is pending for this leg or srfConnection; 

a tariffSwitchlnterval for the "CSE control of call duration" is indicated when a previously received 
tariffSwitchlnterval for the "CSE control of call duration" is pending for the Called Party, the Temporary 
Connection or the connection to a gsmSRF. 

Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting 
operation errors are described in clause 14. 

1 1 .3 ApplyChargingReport procedure 
1 1 .3.1 General description 

The gsmSSF uses this operation to report charging related information to the gsmSCF as requested by the gsmSCF 
using the "ApplyCharging" operation. 

For a change in a connection configuration of the legs - on CPH - this operation shall be sent as an indication towards 

the gsmSCF that the supervision of that part of the connection is finished; i.e. 

(i) the gsmSCF shall settle the account using the reported duration and 

(ii) the durations reported for subsequent AC/ACR cycles will not be accumulated to the reported duration. 
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If Answer is detected by the gsmSSF, then timing of duration shall be started as requested by the ApplyCharging 
operation. It shall be started independently for a connection to a Called Party, a Temporary Connection and a gsmSRF 
connection. 

The charging report shall be generated as specified in the 3GPP TS 23.078 [7]. 

The tariff switch mentioned in the following subclause is the tariff switch for "CSE control of call duration" for the 
connection to which the ApplyChargingReport procedure applies. 

11.3.1.1 Parameters 

callResult: 

This parameter provides the gsmSCF with the charging related information previously requested using the 

ApplyCharging operation. The "CallResult" is a list and may contain the following parameters: 

timeDurationChargingResult: 

This parameter is a list, and can contain the following parameters: 

- timelnformation: 

This parameter is a choice of the following parameters: 

- timelfNoTariffSwitch: 

This parameter shall be present if no tariff switch has occurred since the reception of the first 

ApplyCharging operation for the connection to the Called Party, Temporary Connection or gsmSRF 

connection, otherwise it shall be absent. 

If Answer was detected for the connection to the Called Party, the Temporary Connection or the gsmSRF 

connection, then the elapsed time since detection of Answer shall be reported. If answer was not detected, 

then it shall be set to "0". 

For a change in the connection configuration of the legs - on CPH - the particular point in time when the 

new connection configuration is established shall be taken as Answer time. 

timelfTariffS witch: 

This parameter shall be present if a tariff switch has occurred since the reception of the first 

ApplyCharging operation for the connection to the Called Party, Temporary Connection or gsmSRF 

connection, otherwise it shall be absent. 

The parameter may contain the following information: 

timeSinceLastTariffS witch: 

If Answer was detected for the connection to the Called Party, the Temporary Connection or the 

gsmSRF connection, then the elapsed time since detection of Answer or the last tariff switch 

(whichever of these events was last detected) shall be reported. If Answer was not detected, then it 

shall be set to "0". 

For a change in the connection configuration of the legs - on CPH - the particular point in time 

when the new connection configuration is established shall be taken as Answer time. 

TariffSwitchlnterval (for the "CSE control of call duration"): 

This parameter is present only if a tariff switch has occurred since the detection of Answer for the 

connection to the Called Party, the temporary connection or the gsmSRF connection in the 

reported call period. 

The time interval between either the detection of the Answer event or the previous tariff switch 

(whichever of these events was last detected) and the last tariff switch is reported. 

For a change in the connection configuration of the legs - on CPH - the particular point in time 

when the new connection configuration is established shall be taken as Answer time. 

partyToCharge: 

The "partyToCharge" parameter as received in the related ApplyCharging operation or deduced from the default 

value. This parameter is used by the gsmSCF, to correlate the result to the request. 

aChChargingAddress: 

The "aChChargingAddress" parameter as received in the related ApplyCharging operation or deduced from the 

default value. This parameter is used by the gsmSCF, to correlate the result to the request. 
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leg Active: 

This parameter indicates whether the leg, the Temporary Connection or the connection to a gsmSRF is still 

active or has been released. 

callLegReleasedAtTcp Expiry : 

This parameter indicates that the gsmSSF has released the call leg or the Temporary Connection or SRF 

connection 

1 1 .3.2 Invoking entity (gsmSSF) 

11.3.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A relationship exists between the gsmSSF and the gsmSCF. 

(2) A charging event has been detected that was requested by the gsmSCF via an ApplyCharging operation or a 
Called Party, Temporary Connection or gsmSRF disconnection event has occurred. 

gsmSSF postconditions: 

(1) If release of the call has occurred because the allowed call duration has been reached, then: 

All armed EDPs shall be disarmed; 

ApplyChargingReport shall be sent to gsmSCF followed by any pending CalllnformationReports; 

- The gsmSSF FSM shall transit to the state "Idle". 

(2) If release of the call has occurred but not because the allowed call duration has been reached, then: 

If there are any armed EDPs or pending reports, then the gsmSSF FSM shall remain in the same state, else; 

- The gsmSSF FSM shall transit to the state "Idle". 

(3) else: 

- no gsmSSF FSM state transition. 

11.3.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services used for reporting 
operation errors are described in clause 14. 

1 1 .4 AssistRequestlnstructions procedure 



1 1 .4.1 General description 



This operation may be used by an assist gsmSSF or by a gsmSRF. The operation is sent to the gsmSCF when the 
assisting gsmSSF or gsmSRF receives an indication from an initiating gsmSSF indicating an assist procedure. 

11.4.1.1 Parameters 

correlationID: 

This parameter is used by the gsmSCF to associate the "AssistRequestlnstructions" from the assisting gsmSSF or 
by a gsmSRF with the request from the initiating gsmSSF. The value of the "correlationID" may be extracted 
from the digits received from the initiating gsmSSF. 

- iPSSPCapabilities: 

Indicates which gsmSRF resources are attached, available and supported within: 

the MSC where the assisting gsmSSF resides; or 
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the IP where the gsmSRF resides. 

1 1 .4.2 Invoking entity (gsmSSF/gsmSRF) 

11.4.2.1 Normal procedure 

assisting gsmSSF or gsmSRF preconditions: 

(1) An assist indication is detected by the assisting gsmSSF or gsmSRF. 

assisting gsmSSF or gsmSRF postconditions: 

(1) The assisting gsmSSF FSM is in the state "Waiting_for_Instructions" or the gsmSRF FSM is in the state 
'Connected'. 

On receipt of an assist indication from the initiating gsmSSF, the assisting gsmSSF or gsmSRF shall ensure that the 
required resources are available to invoke an "AssistRequestlnstructions" operation in the assist gsmSSF or gsmSRF 
and shall indicate to the initiating gsmSSF that the call is accepted. The "AssistRequestlnstructions" operation is 
invoked by the assist gsmSSF or gsmSRF after the call, which initiated the assist indication, is accepted. 

11.4.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.5 CallGap procedure 
1 1 .5.1 General description 

The gsmSCF uses this operation to request the gsmSSF to reduce the rate at which specific service requests are sent to 
the gsmSCF. This operation may be sent only within a dialogue that has been opened by the gsmSSF by an InitialDP 
operation. 

11.5.1.1 Parameters 

gapCriteria: 

This parameter identifies the criteria for a call to be subject to call gapping. It is a choice of the following 

parameters: "basicGapCriteria" or "compoundGapCrteria": 

- basicGapCriteria: 

This parameter consists of the following parameters: 

calledAddressValue: 

This parameter indicates that call gapping shall be applied when the leading digits of the dialled number of a 
call attempt match those specified in "calledAddressValue". The called address is the one received from the 
current call control. 

gapOnService: 

This parameter indicates that call gapping shall be applied when the Service Key of a Service initiation 

attempt matches the Service Key specified in "gapOnService". 

calledAddressAndService: 

This parameter indicates that call gapping shall be applied when the Service Key of a Service initiation 
attempt matches the Service Key defined in "calledAddressAndService" and the leading digits of the dialled 
number of a that call attempt match the dialled digits defined in "calledAddressAndService". The called 
address is the one received from the current call control. 

callingAddressAndService: 

This parameter indicates that call gapping shall be applied when the Service Key of a Service initiation 

attempt matches the Service Key defined in "callingAddressAndService" and the leading digits of the calling 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 122 ETSI TS 129 078 V8.2.1 (2010-04) 

party number of that call attempt match the calling party number defined in "callingAddressAndService". In 
the case of call forwarding the calling address to be gapped shall the redirecting number which is placed in 
the Initial DP operation. 

- compoundGapCriteria: 

This parameter consists of the folllowing parameters: 

- basicGapCriteria: 

This parameter is as described above. 

- scfTD: 

This parameter identifies a gsmSCF. The scflD shall convey the necessary gsmSCF address information (e.g. 

Global Title) in the network to the requesting gsmSSF. Refer to ITU-T Recommendation Q.713 [42] "calling 

party address" parameter. The network operator shall decide about the actual mapping of this parameter on 

the used signalling system. 

This parameter indicates the address of the gsmSCF which requests the call gapping. 

If scflD is used in an operation that crosses an inter-network boundary, then its encoding must be understood 

in both networks; this requires bilateral agreement on the encoding. If this parameter is not available, then the 

call gapping is not dedicated to a specific gsmSCF. 

This parameter is restricted to include a fixed GT address string. 

NOTE: In the case where the GT addresses more than one SCP (e.g. a mated pair), then if one of these 

physical SCPs enters an overload conditions and issues a CallGap instruction, then the CallGap is 
applied to all these SCPs. 

gaplndicators: 

This parameter indicates the call gapping characteristics. 

duration: 

This parameter specifies the total time interval during which call gapping for the specified gap criteria will be 
active. 

A duration of indicates that call gapping shall be removed. 

A duration of -2 indicates a network specific duration. 

Other values indicate duration in seconds. A duration of -1 shall not be used. 

gaplnterval: 

This parameter specifies the minimum time between calls being allowed through. 

An interval of indicates that calls meeting the gap criteria shall not be rejected. 

An interval of -1 indicates that all calls meeting the gap criteria shall be rejected. 

Other values indicate the gap interval in milliseconds. 

controlType: 

This parameter indicates the reason for activating call gapping. 

The "controlType" value "sCPOverloaded" indicates that an automatic congestion detection and control 
mechanism in the SCP has detected a congestion situation. 

The "controlType" value "manuallylnitiated" indicates that the service, the network managent centre or service 
management centre, or both has detected a congestion situation, or any other situation that requires manually 
initiated controls. 

NOTE: The controlType "manuallylnitiated" shall have priority over "sCPOverloaded" call gap. Also non- 
CAMEL controlled traffic control mechanism may apply to an exchange with the gsmSSF 
functionality. The non-CAMEL controlled traffic control may also have some influence to the CAMEL 
call. It is therefore recommended to take measures to co-ordinate several traffic control mechanisms. 
The non-CAMEL controlled traffic control and co-ordination of several traffic control mechanisms are 
out of the scope of CAP. 

- gapTreatment: 

This parameter indicates how calls that were stopped by the call gapping mechanism shall be treated. 
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inf ormationTo S end : 

This parameter indicates an announcement or a tone to be sent to the calling party. At the end of information 
sending, the call shall be released. 

inbandlnfo: 

This parameter specifies the inband information to be sent. 

messagelD: 

This parameter indicates the message(s) to be sent, it can be one of the following: 

elementaryMessagelD: 

This parameter indicates a single announcement. 

- duration: 

This parameter indicates the maximum time duration in seconds that the message shall be played or 
repeated. A value of "0" indicates endless repetition. 

tone: 

This parameter specifies a tone to be sent to the end-user. 

- tonelD: 

This parameter indicates the tone to be sent. 

duration: 

This parameter indicates the time duration in seconds of the tone. A value of "0" indicates infinite 

duration. 

releaseCause: 

If the call shall be released, then this parameter indicates a specific cause value to be sent in the release 

message. See ETSI EN 300 356-1 [23]. 

1 1 .5.2 Responding entity (gsmSSF) 
1 1 .5.2.1 Normal procedure 

gsmSSF preconditions: 

(1) Call gapping for gapCriteria is not active; or 
Call gapping for gapCriteria is active. 

(2) The gsmSSF FSM is in any state except "Idle" and except "Wait_For_Request". 
gsmSSF postconditions: 

(1) The gsmSSME FSM is in the state "Active". 

(2) Call gapping for gapCriteria is activated; or 
Call gapping for gapCriteria is renewed; or 
Call gapping for gapCriteria is removed. 

(3) No gsmSSF FSM state transition. 

If there is not already an existing gsmSSME FSM for the gap criteria and gsmSCFAddress provided, then a new 
gsmSSME FSM shall be created. If no gsmSCFAddress is provided, then this refers in general to the gsmSSME FSM 
without a gsmSCFAddress. This gsmSSME FSM enters the state "Active" and initialises call gapping for the specified 
CAMEL calls. The parameters "gaplndicators", "controlType", "gapTreatment" and "gsmSCFAddress" for the indicated 
gap criteria shall be set as provided by the "CallGap" operation. 

In the case that both "manuallylnitiated" and "sCPOverloaded" call gapping are active for the same "gapCriteria", the 
manuallylnitiated call gapping shall prevail over the "sCPOverloaded" call gapping. More specifically, the following 
rules shall be applied in the gsmSSF to manage the priority of different control Types associated with the same 
"gapCriteria": 
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If a gsmSSME FSM already exists for the "gapCriteria" and the gsmSCFAddress provided, then: 

(1) If the (new) "controlType" equals an existing "controlType", then the new parameters (i.e.,"gapIndicators" 
and "gapTreatment") shall overwrite the existing parameters. 

(2) If the (new) "controlType" is different from the existing "controlType", then the new parameters (i.e., 
"controlType", "gaplndicators" and "gapTreatment") shall be appended to the appropriate gsmSSME FSM 
(in addition to the existing parameters). The gsmSSME FSM remains in the state "Active". 

If the gsmSSF meets a TDP, then it shall check if call gapping was initiated for the same gsmSCF as the one currently 
assigned to this TDP or if call gapping exists with no provided gsmSCFAddress. If neither call gapping was initiated 
nor exists, then an "InitialDP" operation may be sent. 

The gsmSSF shall check if call gapping was initiated either for the "serviceKey" or for the "calledAddressValue" 
assigned to this TDP. If this is not the case, then an "InitialDP" operation may be sent. If call gapping was initiated for 
"calledAddressAndService" or "callingAddressAndService" and the "serviceKey" matches, then a check on the 
"calledAddressValue" and "callingAddressValue" for active call gapping shall be performed. Otherwise, an "InitialDP" 
operation may be sent. 

If a call to a controlled number matches one "gapCriteria" only, then the corresponding control is applied. If both 
"manuallylnitiated" call gapping and "sCPOverload" call gapping controls are active, then only the "manuallylnitiated" 
call gapping shall be applied. 

If a call matches several active "basicGapCriteria", then the treatment as specified in the CallGap associated with the 
gapCriteria with the highest priority shall be applied, with the priority being from high to low: 

1 . calledAddressAndService or calledAddressValue; 

2. callingAddressAndService; 

3. gapOnService. 

For example, a call with called number 123456 and ServiceKey = NP matches two CallGaps, one with gapCriteria 
"CalledAdressValue=123" and another one with gapCriteria "gapOnService=NP". Then the call shall be subject to the 
control of the service request CallGap with "CalledAdressValue=123". 

In the case that multiple call gapping procedures are active with the same gap criteria, the "manuallylnitiated" call 
gapping shall prevail over the "sCPOverloaded" call gapping. 

If a call to a controlled called number or from a controlled calling number matches several active "basicGapCriteria " of 
the same type (in this context "calledAddressAndService" and "calledAddressValue" are seen as one type), then only 
the "gapCriteria" associated with the longest called party number shall be used, and the corresponding control shall be 
applied. For example, the codes 1234 and 12345 are under control. Then the call with 123456 is subject to the control 
on 12345. 

If a call to a controlled called number matches calledAddressAndService and calledAddressValue with the same 
number length, then calledAddressAndService has priority. Furthermore, if both "manuallylnitiated" and 
"sCPOverloaded" "controlTypes" are active for this "gapCriteria", then the "manuallylnitiated" control shall be applied. 

If call gapping is performed on a call for a particular service and triggering of this service is allowed, then no other gap 
criteria shall be applied this service instance. 

Active GapCriteria with assigned scflD shall have higher priority than the other GapCriteria. In the case that an entry 
with scflD matching the current call exists, all other criteria without scflD shall not be evaluated. 

The matching entries with scflD shall be evaluated in accordance with the priority rules for the basic criteria listed 
above. 

If call gapping shall be applied and there is no gap interval active, then an "InitialDP" operation may be sent including 
the "cGEncountered" parameter in accordance with the specified controlType. A new gap interval shall be initiated as 
indicated by "gaplnterval". 

If a gap interval is active, then no "InitialDP" operation shall be sent and the call shall be treated as defined by Default 
Call Handling of the valid CSI and "gapTreatment". 

If the indicated duration equals "0", then the call gap process shall be stopped. 
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If call gapping proceeds, then the gsmSSME FSM remains in the state "Active". Otherwise, the gsmSSME FSM transits 
to the state "idle". 

11.5.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

1 1 .6 CalllnformationReport procedure 

1 1 .6.1 General description 

The gsmSSF uses this operation to send specific call information for a single call party to the gsmSCF as requested by 
the gsmSCF in previous "CalllnformationRequest" operation. The report shall be sent at the end of a call party 
connection which is indicated by one of the events specified below. 

11.6.1.1 Parameters 

requestedlnformationList: 

The gsmSSF sends the appropriate types and values to the gsmSCF in accordance with the requested 

information. 

- legID: 

This parameter indicates the party in the call for which the information has been collected. 

1 1 .6.2 Invoking entity (gsmSSF) 
1 1 .6.2.1 Normal procedure 

gsmSSF preconditions: 

(1) The indicated or default party is released from the call or call setup towards the indicated or default party is 
terminated prematurely. 

(2) Requested call information has been collected. 

(3) "CalllnformationReport" is pending due to a previously received "CalllnformationRequest" operation. 

(4) A control or a monitor relationship exists between the gsmSCF and the gsmSSF. 

gsmSSF postconditions: 

(1) If there are no armed EDPs or pending reports, then the gsmSSF FSM shall transit to the state "Idle"; otherwise, 
the gsmSSF FSM shall remain in the same state. 

If the gsmSSF FSM executes a state transition caused by one of the following events: 

release for the indicated or default leg; 

abandon for the indicated or default leg; 

Called party Busy or Not Reachable for the indicated or default leg; 

gsmSSF No_Answer timer expiration for the indicated or default leg; 

route select failure for the indicated or default leg; 

release of call initiated by the gsmSCF (ReleaseCall), 

and "CalllnformationRequest" is pending for the indicated or default leg, then one "CalllnformationReport" operation 
shall be sent to the gsmSCF, containing all information requested for that leg. 
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If a "CalllnformationReport" has been sent to the gsmSCF, then no "CalllnformationReport" is pending on that leg, i.e. 
if a further "CalllnformationReport" on that leg is required, for example in the case of follow-on call, then this has to be 
explicitly requested by the gsmSCF. 

11.6.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

1 1 .7 CalllnformationRequest procedure 

11 .7.1 General description 

The gsmSCF uses this operation to request the gsmSSF to record specific information about a single call party and 
report it to the gsmSCF using the "CalllnformationReport" operation. 

11.7.1.1 Parameters 

requestedlnformationTypeList: 

This parameter specifies a list of specific items of information which is requested. The list may contain the 

following parameters: 

call AttemptElap sedTime : 

This parameter indicates the duration between the end of CAP processing of operations initiating call setup 
("Connect", "Continue" or "ContinueWithArgument") and the received answer indication from the called 
party. If the callAttemptElapsedTime is requested for the calling party, then a value of "0" shall be reported 
by the gsmSSF. 

In the case of unsuccessful call setup, the network event indicating the unsuccessful call setup stops the 
measurement of "callAttemptElapsedTime". 

- callStopTime: 

This parameter indicates the time stamp when the connection is released. 

callConnectedElapsedTime: 

This parameter indicates the duration between the received answer indication from the called party and the 
release of that connection. For the calling party it indicates the duration between the sending of InitialDP and 
the release of that party. 

releaseCause: 

This parameter indicates the release cause for the call. 

- legID: 

This parameter indicates the party in the call for which the information shall be collected. 

1 1 .7.2 Responding entity (gsmSSF) 
1 1 .7.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between gsmSSF and gsmSCF. 

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions". 
gsmSSF postconditions: 

(1) Requested call information is retained by the gsmSSF. 

(2) No gsmSSF FSM state transition. 
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The gsmSSF allocates a record for the indicated or default party and stores the requested information if already 
available and prepares the recording of information items, that will become available later like for example 
"callStopTimeValue". 

Call information may be requested for any call party (identified by a legID). 

11.7.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .8 Cancel procedure 

1 1 .8.1 General description 

The gsmSCF uses this operation to request the gsmSRF or gsmSSF to cancel a correlated previous operation. 
The Cancel operation may be used for the following purposes: 

(1) Cancel may be sent to the gsmSRF to cancel the "Play Announcement" or the "PromptAndCollectUserlnformation" 
operation. The cancellation of the operation is indicated via a respective error indication, "Canceled", to the 
invoking entity of the cancelled "Play Announcement" or "PromptAndCollectUserlnformation" operation. 

(2) Cancel may be sent to the gsmSSF to disarm all armed EDPs and cancel all pending reports. This enables the 
gsmSSF FSM to transit to the state "Idle". If Cancel is used for this purpose, then the Cancel operation does not 
specify any specific operation to be cancelled. 

11.8.1.1 Parameters 

invokelD: 

This parameter specifies which operation invocation shall be cancelled, i.e. PromptAndCollectUserlnformation 

or Play Announcement. 

callSegmentID: 

This parameter specifies the Call Segment to which the cancellation of the user interaction operation shall apply. 

allRequests: 

This parameter indicates that all armed EDP shall be disarmed and that any pending "ApplyChargingReport" and 

"CalllnformationReport" shall be cancelled. 

1 1 .8.2 Responding entity (gsmSRF) 

In the case of Cancel(invokelD), the gsmSRF is the responding entity. In this case, the Cancel operation may also 
contain the callSegmentID parameter. 

1 1 .8.2.1 Normal procedure 

gsmSRF preconditions: 

(1) A Play Announcement or PromptAndCollectUserlnformation operation has been received and the gsmSRF FSM 
is in the state "User Interaction". 
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gsmSRF postconditions: 

(1) The execution of the Play Announcement or PromptAndCollectUserlnformation operation has been aborted and 
the gsmSRF remains in the state "User Interaction". 

11.8.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .8.3 Responding entity (gsmSSF) 

In the case of Cancel(allRequests), the gsmSSF is the responding entity. 

1 1 .8.3.1 Normal procedure 

gsmSSF preconditions: 

(1) The gsmSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 
gsmSSF postconditions: 

(1) All armed EDPs are disarmed and all pending reports are cancelled. 

(2) If the gsmSSF FSM was in the state "Monitoring", then it shall transit to the state "Idle"; or 

If the gsmSSF FSM was in the state "Waiting_for_Instructions", then it shall remain in that state. 

A subsequent call-processing operation will result in a gsmSSF FSM state transition to the state "Idle". If the call 

is in the active state, then the gsmSSF shall treat it autonomously as a normal (non-CAMEL) call. 

11.8.3.2 Error handling 

Sending of return error on cancel is not applicable in the cancel "allRequests" case. Generic error handling for the 
operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are 
described in clause 14. 

1 1 .8A Collectlnformation Procedure 
1 1 .8A.1 General description 

The gsmSCF uses this operation to request the gsmSSF to perform the call processing actions to collect additional digits 
from the calling party and report it to the gsmSCF. The Collectlnformation operation may be used for TO calls in the 
gsmSSF. The gsmSCF shall arm the Collected_Info DP as EDP-R before sending this operation. 

11.8A.1.1 Parameters 

None 

Note: An operation argument is supported for future extensibility. 

1 1 .8A.2 Responding entity (gsmSSF) 
11.8A.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSCF and the gsmSSF; 

(2) Basic call processing has been suspended at Collectedlnfo DP or Analysedlnfo DP; 
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(3) Collectedlnfo DP has been armed as EDP-R; 

(4) The gsmSSF FSM is in the state "Waiting_for_Instructions". 
gsmSSF postconditions: 

(1) The gsmSSF performs the call processing actions to collect additional dialled digits from the calling party; 

(2) The gsmSSF FSM transits to the state 'Monitoring'; 

(3) In the O-BCSM, call processing resumes at PIC Collectjnfo or PIC Analyzejnformation. 

11.8A.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .9 Connect procedure 
1 1 .9.1 General description 

The gsmSCF uses this operation to request the gsmSSF to perform the call processing actions to route a call to a 
specific destination. 

In general all parameters which are provided in a Connect operation to the gsmSSF shall replace the corresponding 
signalling parameter in the CCF in O-BCSM, in accordance with ETSI ES 201 296 [21] and shall be used for 
subsequent call processing. The CCF of the T-BCSM shall send corresponding signalling parameters to new call leg 
without using them in subsequent call processing. Parameters which are not provided by the Connect operation shall 
retain their value (if already assigned) in the CCF for subsequent call processing. 

11.9.1.1 Parameters 

destinationRouting Address: 

This parameter contains the called party numbers towards which the call shall be routed. 

alertingPattern: 

This parameter indicates the type of alerting to be applied. It is defined in 3GPP TS 29.002 [11]. 

servicelnteractionlndicatorsTwo : 

This parameter contains indicators to resolve interactions between CAMEL based services and network based 

services. 

callingPartysCategory: 

This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

originalCalledPartylD: 

If the call is forwarded by the gsmSCF, then this parameter carries the dialled digits. 

redirectingPartylD: 

This parameter indicates the last directory number the call was redirected from. 

redirectionlnformation: 

This parameter contains forwarding related information, such as redirecting counter. 

genericN umbers: 

This parameter allows the gsmSCF to set the Generic Number parameter used in the network. It is used for transfer 

of Additional Calling Party Number. 

suppressionOf Announcement: 

This parameter indicates that announcements and tones which are played in the exchange at non-successful call 

set-up attempts shall be suppressed. 
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oCSIApplicable: 

This parameter indicates to the GMSC/gsmSSF or VMSC/gsmSSF that the Originating CAMEL Subscription 
Information, if present, shall be applied on the outgoing call leg created with the Connect operation. For the use of 
this parameter see 3GPP TS 23.078 [7]. 

Carrier: 

This parameter indicates carrier information. It consists of the carrier selection field followed by the Carrier ID 

information to be used by gsmSSF for routeing a call to a carrier. 

It contains the following embedded parameters: 

carrierSelectionField: 

This parameter indicates how the selected carrier is provided (e.g. pre-subscribed). 

carrierlD: 

This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code. 

naOlilnfo: 

This parameter contains originating line information which identifies the charged party number type to the carrier. 

ChargeNumber: 

This parameter contains the number that identifies the entity to be charged for the call. It identifies the chargeable 
number for the usage of a carrier (applicable on a call sent into a North American long distance carrier). For a 
definition of this parameter refer to ANSI Tl. 1 13-1995 [92]. 

cug-Interlock: 

This parameter uniquely identifies a CUG within a network. 

cug-OutgoingAccess: 

This parameter indicates if the calling user has subscribed to the outgoing access inter-CUG accessibility 

subscription option. 

bor-InterrogationRequested: 

This parameter indicates that Basic Optimal Routeing is requested for the call. 

legToBeConnected: 

This parameter indicates the leg to be connected. 

suppress-N-CSI: 

This parameter indicates that N-CSI shall be suppressed 

1 1 .9.2 Responding entity (gsmSSF) 
1 1 .9.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSSF and the gsmSCF. 

(2) Basic call processing has been suspended at a DP. 

(3) The gsmSSF FSM is in the state "Waiting_for_Instructions". 
gsmSSF postconditions: 

(1) The gsmSSF performs the call processing actions to route the call to the specified destination. 

(2) In the O-BCSM, call processing resumes at PIC Analyze_Information. 

On receipt of this operation, the gsmSSF performs the following actions: 

If no EDPs have been armed and neither a CalllnformationReport nor an ApplyChargingReport has been 
requested, then the gsmSSF FSM transits to the state "Idle". Otherwise, the gsmSSF FSM transits to the state 
"Monitoring". 
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The gsmSSF shall not perform any implicit arming or disarming of DPs. 
Statistic counter(s) are not affected. 

11.9.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.10 ConnectToResource procedure 

11.10.1 General description 

The gsmSCF uses this operation to connect a call segment from the gsmSSF to a specialized resource. After successful 
connection to the gsmSRF, the interaction with the parties in the call segment can take place. The gsmSSF relays all 
operations for the gsmSRF and all responses from the gsmSRF. 

11.10.1.1 Parameters 

resourceAddress: 

This parameter identifies the physical location of the gsmSRF. It may be one of the following parameters. 

- iPRoutingAddress: 

This parameter indicates the routeing address to set up a connection towards the gsmSRF. 

none: 

This parameter indicates that the call segment shall be connected to a predefined gsmSRF. 

servicelnteractionlndicatorsTwo: 

This parameter contains an indicator that is used for the control of the through connection to the Calling Party. 

NOTE The call segment to which the ConnectToResource applies does not have to contain a leg to the 
calling party. 

The assisting gsmSSF shall always assume that Bothway Throughconnection is required, and hence will ignore 
this parameter if received. 

callSegmentld: 

This parameter indicates the call segment to which the Connect To Resource procedure applies. 

11.10.2 Responding entity (gsmSSF) 
1 1 .1 0.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSCF and the gsmSSF. 

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions". 
gsmSSF postconditions: 

(1) The call segment is connected to the gsmSRF. 

(2) A control relationship between the gsmSCF and the gsmSRF is established. 

(3) The gsmSSF FSM transits to the state "Waiting_for_end_of_User_Interaction". 

NOTE: The successful connection to the gsmSRF causes a gsmSRF FSM state transition from the state "Idle" to 
the state "Connected". 
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11.10.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.11 Continue procedure 

11.11.1 General description 

The gsmSCF uses this operation to request the gsmSSF to proceed with call processing at the DP at which it previously 
suspended call processing to await gsmSCF instructions. The gsmSSF continues call processing without substituting 
new data from the gsmSCF. 

11.11.1.1 Parameters 

None. 

11.11.2 Responding entity (gsmSSF) 

11.11.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSSF and the gsmSCF. 

(2) Basic call processing has been suspended at any DP. 

(3) The gsmSSF FSM is in the state "Waiting_for_Instructions". 
gsmSSF postconditions: 

(1) BCSM: If the Call Segment has received all the required resumptions then basic call processing continues. 

(2) The gsmSSF FSM remains in the same state unless all resumptions have been received. 

If all resumptions have been received, then: 

If there are armed EDPs or pending reports and no user interaction is ongoing, then the gsmSSF FSM transits 
to the state "Monitoring"; or 

If there are no armed EDPs neither pending reports, then the gsmSSF FSM transits to the state "Idle". 

11.11.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

11.12 ContinueWithArgument Procedure 
11.12.1 General description 

The gsmSCF uses this operation to request the gsmSSF to proceed with call processing at the DP at which it previously 
suspended call processing to await gsmSCF instructions. It is also used to provide additional service related information 
to a User (Called Party or Calling Party) whilst the call processing proceeds. 

In general all parameters which are provided in a ContinueWithArgument operation to the gsmSSF shall replace the 
corresponding signalling parameter in the CCF, in accordance with ETSI ES 201 296 [21], and shall be used for 
subsequent call processing. Parameters which are not provided by the ContinueWithArgument operation shall retain 
their value (if already assigned) in the CCF for subsequent call processing. 
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11.12.1.1 Parameters 

- legOrCallSegment: 

This parameter indicates the leg or Call Segment to which the Continue WithArgument operation shall apply. 

alertingPattern: 

This parameter indicates the type of alerting to be applied. It is defined in 3GPP TS 29.002 [11]. 

servicelnteractionlndicatorsTwo: 

This parameter contains indicators that are used to resolve interactions between CAMEL based services and 

network based services. 

- callingPartysCategory: 

This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

genericNumbers : 

This parameter allows the gsmSCF to set the Generic Number parameter used in the network. It is used for 

transfer of Additional Calling Party Number. 

suppressionOf Announcement: 

This parameter indicates that announcements and tones which are played in the exchange at non-successful call 

set-up attempts shall be suppressed. 

carrier: 

This parameter indicates carrier information. It consists of the carrier selection field followed by the Carrier ID 

information to be used by gsmSSF for routeing a call to a carrier. 

It contains the following embedded parameter: 

carrierSelectionField: 

This parameter indicates how the selected carrier is provided (e.g. pre-subscribed). 

carrierlD: 

This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification 

code. 

naOlilnfo: 

This parameter contains originating line information which identifies the charged party number type to the 

carrier. 

chargeNumber: 

This parameter contains the number that identifies the entity to be charged for the call. It identifies the 
chargeable number for the usage of a carrier (applicable on a call sent into a North American long distance 
carrier). For a definition of this parameter refer to ANSI Tl. 113-1995 [92]. 

cug-Interlock: 

This parameter uniquely identifies a CUG within a network. 

cug-OutgoingAccess: 

This parameter indicates if the calling user has subscribed to the outgoing access inter-CUG accessibility 

subscription option. 

- bor-InterrogationRequested: 

This parameter indicates that Basic Optimal Routeing is requested for the call. 

suppress-O-CSI: 

This parameter indicates that O-CSI shall be suppressed for the forwarding leg or deflecting leg. 

suppress-D-CSI: 

This parameter indicates that D-CSI shall be suppressed for the leg. 

- suppress-N-CSI: 

This parameter indicates that N-CSI shall be suppressed for the leg or trunk originated call. 

- suppressOutgoingCallBarring: 

This parameter indicates that outgoing call barrings shall be suppressed for the leg. 
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11.12.2 Responding entity (gsmSSF) 

11.12.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSSF and the gsmSCF. 

(2) Basic call processing has been suspended at a DP. 

(3) The gsmSSF FSM is in the state "Waiting_for_Instructions". 
gsmSSF postconditions: 

(1) BCSM: If the Call Segment has received all the required resumptions then basic call processing continues with 
modified information, 

(2) The gsmSSF FSM remains in the same state unless all resumptions have been received. 
If all resumptions have been received, then: 

If there are armed EDPs or pending reports and no user interaction is ongoing, then the gsmSSF FSM transits 
to the state "Monitoring"; or 

If there are no armed EDPs neither pending reports, then the gsmSSF FSM transits to the state "Idle". 

11.12.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.13 DisconnectForwardConnection procedure 
11.13.1 General Description 

The gsmSCF uses this operation for the following two purposes: 

(1) To clear a connection to a gsmSRF: 

The operation is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a 

"ConnectToResource" or an "EstablishTemporaryConnection" operation. It is used for a forward disconnection 

from the gsmSSF. 

An alternative solution is the backward disconnect from the gsmSRF, controlled by the 

"DisconnectFromlPForbidden" parameter in the "Play Announcement" and "PromptAndCollectUserlnformation" 

operations. 

(2) To clear a connection to an assisting gsmSSF: 

The operation is sent to the non-assisting gsmSSF of a pair of gsmSSFs involved in an assist procedure. It is used to 
disconnect the temporary connection between the initiating gsmSSF and the assisting gsmSSF and the connection 
between the assisting gsmSSF and its associated gsmSRF. 

The DisconnectForwardConnection operation shall not be used when the CallSegmentID is required. 

11.13.1.1 Parameters 

None. 
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11.13.2 Responding entity (gsmSSF) 

1 1 .1 3.2.1 Normal procedure 

gsmSSF preconditions: 

(1) The basic call processing has been suspended at a DP. The gsmSSF FSM in the initiating gsmSSF is in the state 
"Waiting_for_end_of_User_Interaction" or in the state "Waiting_for_end_of_Temporary_Connection". 

gsmSSF postconditions: 

(1) The connection to the gsmSRF or assisting gsmSSF is released. 

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions". 

The receipt of "DisconnectForwardConnection" results in a disconnection of the assisting gsmSSF or the PE containing 
the gsmSRF from the call. It does not result in a release of the connection between the gsmSSF and the end-user. 

On receipt of this operation, the gsmSSF shall perform the following actions: 

The initiating gsmSSF releases the connection to the assisting gsmSSF or the gsmSRF. 

The gsmSSF FSM transits to the state "Waiting_for_Instructions". 

NOTE: The successful disconnection to the gsmSRF causes a gsmSRF FSM state transition to the state "Idle". A 
current order (e.g. "Play Announcement" or "PromptAndCollectUserlnformation") is cancelled and any 
queued order (e.g. "Play Announcement" or "PromptAndCollectUserlnformation") is discarded. 

11.13.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.14 DisconnectForwardConnectionWithArgument procedure 

11.14.1 General Description 

The gsmSCF uses this operation to disconnect a connection to a resource (gsmSRF) established previously with a 
"ConnectToResource" or an "EstablishTemporaryConnection" operation. 

11.14.1.1 Parameters 

callSegmentID: 

This parameter indicates the Call Segment to be disconnected from the resource. 

11.14.2 Responding entity (gsmSSF) 
11.14.2.1 Normal procedure 

gsmSSF preconditions: 

(1) The basic call processing has been suspended at a DP. The CS_gsmSSF FSM in the initiating gsmSSF is in the 
state "Waiting_for_end_of_User_Interaction" or in the state "Waiting_for_end_of_Temporary_Connection". 

gsmSSF postconditions: 

(1) The connection to the gsmSRF or assisting gsmSSF is released. 

(2) The CS_gsmSSF FSM transits to the state "Waiting_for_Instructions". 
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The receipt of "DisconnectForwardConnectionWithArgument" results in disconnecting the PE containing the gsmSRF 
from the specified Call Segment. It does not result in a release of the connection between the gsmSSF and the end-user. 

On receipt of this operation, the gsmSSF shall perform the following actions: 

The gsmSSF releases the connection to the assisting gsmSSF or the gsmSRF. 

The gsmSSF FSM transits to the state "Waiting_for_Instructions". 

NOTE: The successful disconnection from the gsmSRF causes the gsmSRF to transit to the state "Idle". A current 
order (e.g. "Play Announcement" or "PromptAndCollectUserlnformation") is cancelled and any queued 
order (e.g. "Play Announcement" or "PromptAndCollectUserlnformation") is discarded. 

11.14.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.15 DisconnectLeg procedure 

11.15.1 General Description 

The gsmSCF uses this operation to request the gsmSSF to release a specific leg associated with the call. Any other 
leg(s) not specified in the Disconnect Leg operation are retained. 

11.15.1.1 Parameters 

legToBeReleased: 

This parameter indicates the call leg to be released. 

- releaseCause: 

This parameter may be used by the MSC for generating specific tones to the party to be released or to fill in the 
"cause" parameter in the release message. 

11.15.2 Responding entity (gsmSSF) 
1 1 .1 5.2.1 Normal procedure 

gsmSSF preconditions: 

1) A control relationship exists between the gsmSCF and the gsmSSF; 

2) User interaction is not in progress in the Call Segment containing the leg to be disconnected. 
gsmSSF postconditions: 

1) The gsmSSF performs the call processing actions to release the indicated party. 

2) Any armed EDPs on that leg shall be disarmed; any pending reports for that leg shall be sent to the gsmSCF. 

3) If the released leg was the last leg within the Call Segment, then the CS_gsmSSF FSM for that Call Segment 
returns to the state "Idle". 

4) If the leg was the last leg within the call, then the CSA_gsmSSF FSM returns to the state "Idle". 

5) If the CS_gsmSSF FSM for the Call Segment concerned has not returned to the state "Idle", then it transits to the 
state "Waiting_for_Instructions". The remaining BCSM instances within the Call Segment shall transit to the 
0_Mid_Call DP or to the T_Mid_Call DP, unless already suspended at a DP. The Mid_Call EDP shall not be 
reported for this case. 

6) A Return Result shall be sent to the gsmSCF immediately after successful execution of this operation. 
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11.15.2.2 Error handling 

Generic error handling for the operation related errors is describer in clause 10, and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.16 EntityReleased procedure 

11.16.1 General Description 

The CS A uses this operation to inform the gsmSCF about the release of a logical entity (Call Segment or BCSM) 
caused by exception or errors. The CSA shall use this operation if this information can not be conveyed in a 
TC_ABORT or TC_END TC message because the TC dialogue has to be maintained for other logical entities (Call 
Segment or BCSM) in this CSA which are not affected by this error or exception. The CSA shall not use this operation 
if the last Call Segment in the CSA was released. 

11.16.1.1 Parameters 

This operation consists of a choice of the following parameters: 

- CSFailure: 

Indicates that a Call Segment was released. It contains of the following parameters: 

callSegmentID: 

This parameter identifies the released Call Segment. 

cause: 

This parameter indicates the cause for releasing this Call Segment. The cause may be used by the gsmSCF to 

decide the further handling of the call. 

- BCSMFailure: 

This parameter indicates that a leg was released. It consists of the following parameters: 

- legID: 

This parameter identifies the released leg. 

cause: 

This parameter indicates the cause for releasing this BCSM. The cause may be used by the gsmSCF to decide 

the further handling of the call. 

11.16.2 Invoking entity (gsmSSF) 

1 1 .1 6.2.1 Normal procedure 

CSA_gsmSSF preconditions: 

(1) Any CSA_gsmSSF FSM state except "Idle". 

CSA_gsmSSF postconditions: 

gsmSSF postconditions: 

(1) If the released entity was a BCSM (leg), then only the appropriate resources are released. If the released entity 
was a Call Segment, then the related CS_gsmSSF FSM returns to the state "Idle". 

11.16.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for 
reporting operation errors are described in clause 14. 
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11.17 EstablishTemporaryConnection procedure 
11.17.1 General Description 

The gsmSCF uses this operation to create a connection between an initiating gsmSSF and an assisting gsmSSF as part 
of a service assist procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF, for the case 
where the gsmSRF exists in a separately addressable PE. 

The assistingSSPIPRoutingAddress shall contain routeing digits, a correlationID and a scflD when a temporary 
connection shall be established between PLMNs and no bilateral agreement exists between the involved network 
operators to transfer correlationID and SCFiD as separate parameters. 

11.17.1.1 Parameters 

assistingSSPIPRoutingAddress: 

This parameter indicates the destination address of the gsmSRF for assist procedure. The 
"assistingSSPIPRoutingAddress" may contain embedded within it, a "correlationID" and "scflD", but only if 
"correlationID" and "scflD" are not specified separately. 

correlationID: 

This parameter is used by the gsmSCF to associate the "AssistRequestlnstructions" from the assisting gsmSSF 
(or the gsmSRF) with the Request from the initiating gsmSSF. The "correlationID" shall be used only if the 
correlation id is not embedded in the "assistingSSPIPRoutingAddress". The network operator has to decide about 
the actual mapping of this parameter on the used signalling system. 

- scflD: 

This parameter contains the gsmSCF identifier and enables the assisting gsmSSF to identify which gsmSCF the 
AssistRequestlnstructions shall be sent to. 

The "scflD" shall be used only if the gsmSCF id is not embedded in the "assistingSSPIPRoutingAddress". The 
network operator has to decide about the actual mapping of this parameter on the used signalling system. 
When ScflD is used in an operation, which may cross an internetwork boundary, its encoding must be 
understood in both networks; this requires bilateral agreement on the encoding. 

servicelnteractionlndicatorsTwo: 

This parameter contains an indicator that is used for the control of the through connection to the Calling Party. 

- Carrier: 

This parameter contains carrier information. It consists of the carrier selection field followed by the Carrier ID 
information to be used by gsmSSF for routeing a call to a carrier. 

It contains the following embedded parameter: 

carrierSelectionField: 

This parameter indicates how the selected carrier is provided (e.g. pre-subscribed). 

carrierlD: 

This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code. 

naOlilnfo: 

This parameter contains originating line information which identifies the charged party number type to the 

carrier. 

chargeNumber: 

This parameter contains the number that identifies the entity to be charged for the call. It identifies the 
chargeable number for the usage of a carrier (applicable on a call sent into a North American long distance 
carrier). For a definition of this parameter refer to ANSI Tl. 113-1995 [92]. 

callSegmentID: 

This parameter indicates the Call Segment to which the temporary connection shall be established. 

originalCalledPartylD: 

This parameter identifies the original called party. 
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callingPartyNumber: 

This parameter identifies the calling party. 

11.17.2 Responding entity (gsmSSF) 

1 1 .1 7.2.1 Normal procedure 

gsmSSF preconditions: 

(1) The gsmSSF FSM is in the state "Waiting_for_Instructions". 

(2) The gsmSSF is not an assisting gsmSSF. 
gsmSSF postconditions: 

(1) The gsmSSF performs the call processing actions to route the call to the assisting gsmSSF or gsmSRF in 
accordance with the "assistingSSPIPRoutingAddress" requested by the gsmSCF. 

(2) The gsmSSF FSM transits to the state "Waiting_for_end_of_Temporary_Connection". 
On receipt of this operation, the gsmSSF shall perform the following actions: 

Route the call to assisting gsmSSF or gsmSRF using "assistingSSPIPRoutingAddress"; 

11.17.2.2 Error handling 

Until the connection setup has been accepted (refer to ITU-T Recommendation Q.71 [41]) by the assisting gsmSSF or 
the gsmSRF, all received failure indications from the network on the ETC establishment shall be reported to the 
gsmSCF as EstablishTemporaryConnection error ETCFailed (e.g., busy, congestion). 

NOTE The operation timer for EstablishTemporaryConnection shall be longer than the maximum allowed time 
for the signalling procedures to accept the connection. 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.18 EventReportBCSM procedure 
11.18.1 General description 

The gsmSSF uses this operation to notify the gsmSCF of a call related event previously requested by the gsmSCF in a 
"RequestReportBCSMEvent" operation. 

11.18.1.1 Parameters 

- eventTypeBCSM: 

This parameter specifies the type of event that is reported. 

eventSpecificInformationBCSM: 

This parameter indicates the call related information specific to the event. 

For Collectedjnfo it shall contain the CalledPartyNumber parameter. 

For Route_Select_Failure it shall contain the "FailureCause", if available. 

For 0_Busy it shall contain the "BusyCause", if available. 

If the busy event is triggered by an ISUP release message, then the BusyCause is a copy of the ISUP 
release cause, for example: Subscriber absent, 20 or User busy, 17. 

If the busy event is trigerred by a MAP error, for example: Absent subscriber, received from the HLR, 
then the MAP cause is mapped to the corresponding ISUP release cause. 
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NOTE 1 : If no BusyCause is received, then the gsmSCF shall assume busy. 

For T_Busy it may contain the following parameters, if available. 

CallForwarded: 

This parameter indicates that the busy event is triggered by call forwarding at the GMSC or VMSC. 

ForwardingDestinationNumber: 

This parameter indicates the forwarding destination. 

RouteNotPermitted: 

This parameter indicates that the busy event is triggered because call forwarding was not invoked in this 

GMSC due to the rules of Basic Optimal Routeing. 

BusyCause: 

If the busy event is triggered by an ISUP release message, then the BusyCause is a copy of the ISUP 
release cause, for example: Subscriber absent, 20 or User busy, 17. 

If the busy event is triggered by a MAP error, for example: Absent subscriber, received from the 
HLR, then the MAP cause is mapped to the corresponding ISUP release cause. 

If the busy event is triggered by call forwarding or call deflection invocation in the GMSC or VMSC, 
then the BusyCause will refer to the release cause in accordance with the mapping table in 3GPP TS 
23.078 [7]. 

If the busy event is triggered by call forwarding at the GMSC, then the BusyCause reflects the 
forwarding reason (Subscriber Absent, 20 or User busy, 17). The eventSpecificInformationBCSM 
shall in that case also contain the CallForwarded indication. 

NOTE 2: If no BusyCause is received, then the gsmSCF shall assume busy. 

For 0_No_Answer it shall be empty. 

For T_No_Answer it may contain the CallForwarded indication and the ForwardingDestinationNumber. 

If the No_Answer event is triggered by an ISUP release message or expiry of the CAMEL timer 
TNRy, then the eventSpecificInformationBCSM shall be empty. 

If the No_Answer event is triggered by call forwarding at the GMSC or VMSC, then the 
eventSpecificInformationBCSM shall contain the CallForwarded indication and the 
ForwardingDestinationNumber. 

For 0_Answer or T_Answer it shall contain the following information, if available: 

The destination address for the call; 

The OR indicator, in the case that the call was subject to Basic Optimal Routeing, as specified in 3GPP 
TS 23.079 [8]; 

The forwarding indicator, in the case that the Call Forwarding Supplementary Service was invoked; 

The charge indicator; 

- The Extended Basic Service Code, for SCUDIF calls (see 3GPP TS 23.172 [16]); 

- The Extended Basic Service Code 2, for SCUDIF calls (see 3GPP TS 23.172 [16]). 

For 0_Mid_Call and T_Mid_Call it shall contain the detected digit string, in accordance with the criterion defined 
in the RequestReportBCSMEvent operation. 

For Call_Accepted, 0_Term_Seized, 0_Change_Of_Position and T_Change_Of_Position it shall contain the 
following information: 

locationlnformation: 

This parameter indicates the location of the MS. 
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For 0_Disconnect and T_Disconnect it shall contain the "releaseCause", if available. 

For 0_Abandon" it may contain the following parameter, if available. 

- routeNotPermitted: 

This parameter indicates that the O-Abondon event is triggered because call set up shall not be invoked in 
this MSC due to the rules of Basic Optimal Routeing. 

For 0_Service_Change or T_Service_Change it may contain the following information: 

- The Extended Basic Service Code, for SCUDIF calls (see 3GPP TS 23.172 [16]) ; 

The initiator of the Service Change; 

The nature of Service Change. 

- legID: 

This parameter indicates the party in the call for which the event is reported. The gsmSSF shall use the option 
"receivings idelD" only. 

receivings idelD: 

If not included, then the default values for LegID are assumed according to the tables 11-1 and 11-2. 

The "legID" parameter shall always be included for the events 0_Disconnect and T_Disconnect. 

miscCalllnfo: 

This parameter indicates Detection Point (DP) related information. 

- messageType: 

This parameter indicates whether the message is a request, i.e. resulting from a "RequestReportBCSMEvent" 
with monitorMode = interrupted, or a notification, i.e. resulting from a "RequestReportBCSMEvent" with 
"monitorMode" = "notify AndContinue". 

11.18.2 Invoking entity (gsmSSF) 

1 1 .1 8.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship or a monitoring relationship exists between the gsmSSF and the gsmSCF. 

(2) For the 0_Abandon DP and T_Abandon DP, the gsmSSF FSM is in any state, except "Idle". For other DPs, refer 
to 3GPP TS 23.078 [7]. 

(3) The BCSM proceeds to an EDP that is armed. 
gsmSSF postconditions: 

(1) If the message type was notification and there are still armed EDPs or pending reports, then the gsmSSF FSM 
stays in the state "Monitoring". 

(2) If the message type was notification and there are neither any armed EDPs nor pending reports, then the gsmSSF 
FSM transits to the state "Idle". 

(3) If the message type was request, then the gsmSSF FSM transits to the state "Waiting_for_Instructions". Call 
processing is interrupted. 

11.18.2.2 Error handling 

If the message type is "request" and the Tssf timer expires, then the gsmSSF shall abort the TC dialogue and shall 
instruct the MSC to treat the call in accordance with the Default Call Handling, valid for this CAMEL dialogue. 

Operation related error handling is not applicable, due to class 4 operation. 
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11.19 FurnishCharginglnformation procedure 

11.19.1 General description 

The gsmSCF uses this operation to send charging related information to a logical call record. This logical call record is 
CAMEL specific. The first FurnishCharginglnformation operation of a call leg leads to the generation of a logical call 
record. The handling of subsequent FurnishCharginglnformation operations for a call leg depends on the presence and 
value of the append free format data parameter in the FurnishCharginglnformation operation. For details see 3GPP TS 
23.078 [7]. 

If a FurnishCharginglnformation operation is received for the called party when the gsmSSF FSM is in the state 
"Monitoring", or is suspended in one of the following DPs, then the charging information shall be included in the 
logical call record for the leg that has been or is to be established: 

Collectedjnfo; 

Analysed_Information; 

0_Answer; 

Terminating_Attempt_Authorised; or 

T_Answer. 

If a FurnishCharginglnformation operation is received for the called party when the gsmSSF is suspended in any other 
DP, then the charging information shall be included in the logical call record created for the last failed or disconnected 
called party. 

11.19.1.1 Parameters 

fCIBillingChargingCharacteristics: 

This parameter contains the following parameters; 

- fCIBCCC AMELsequence 1 : 

This parameter contains the following parameters; 

freeFormatData: 

This parameter contains free-format billing and/or charging characteristics; 

- partyToCharge: 

This parameter indicates the party to bill and/or charge; 

appendFreeFormatData: 

This parameter indicates whether previous FurnishCharginglnformation free format data is appended or 

overwritten. Refer to 3GPP TS 23.078 [7] for details on the usage of this parameter. 

11.19.2 Responding entity (gsmSSF) 
1 1 .1 9.2.1 Normal procedure 

gsmSSF preconditions: 

(1) The gsmSSF FSM is in the state 

"Waiting_for_Instructions"; or 
"Waiting_for_end_of_User_Interaction"; or 
"Waiting_for_end_of_Temporary_Connection" ; or 
"Monitoring". 

gsmSSF postconditions: 

(1) No gsmSSF FSM state transition. 
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On receipt of this operation the gsmSSF performs actions to create the Logical call record if necessary, and writes the 
free-format information carried in the operation into the Logical call record. A FurnishCharginglnformation operation 
will create a Logical Call Data Record (CDR) if such a record does not already exist for the indicated leg. Refer to sect. 
1 1 .26. 1 for the handling in the case of successive FurnishCharginglnformation operations for a call leg. 

The Logical CDRs will be associated for a given call into one or more physical CDRs, as specified in 3GPP TS 32.250 
[13]. 

A logical call record is output to a physical CDR when a disconnection event is propagated to the call leg associated 
with it, or when a Connect operation to create a connection to a Follow-on Called Party is received. Successive 
FurnishCharginglnformation operationsindicating the calling leg (legl) may overwrite data from previously received 
FurnishCharginglnformation operation(s) indicating that leg during the entire call or call attempt. Successive 
FurnishCharginglnformation operations indicating a called leg (leg2 or higher) may overwrite any previously received 
data from FurnishCharginglnformation operation(s) indicating that called leg until the called leg representing that 
particular called party number is released from the call. When a new called party is created as a result of a follow-on 
call, and a FurnishCharginglnformation operation indicating the called leg is received, then a new Logical call record 
shall be created for that call leg, for that portion of the call. From then on, any subsequent FurnishCharginglnformation 
operations for that called party may overwrite the data from any previous FurnishCharginglnformation operation(s) for 
the called leg presenting that particular called party number. Logical call records that have been output already are not 
affected. 

No Logical call record is output at the end of a user interaction. 

11.19.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

11.20 InitialDP procedure 
1 1 .20. 1 General description 

The gsmSSF uses this operation after detection of a TDP-R in the BCSM, to request the gsmSCF for instructions to 
complete the call. 

11.20.1.1 Parameters 

serviceKey: 

This parameter indicates to the gsmSCF the requested IN service. It is used to address the required application/SLP 

within the gsmSCF; this parameter is not for SCP addressing. 

calledPartyNumber: 

This parameter contains the number used to identify the called party in the forward direction, i.e. see ETSI 

EN 300 356-1 [23]. This parameter shall be sent only in the Mobile Terminating, Mobile Forwarding, mobile 

originating on unsuccessful TDP and trunk originating cases. For the trunk originating case the end of pulsing 

signal (ST) is included in the calledPartyNumber address signals if it has been received or the MSC has determined 

that the called number information is complete. 

callingPartyN umber: 

This parameter carries the calling party number to identify the calling party or the origin of the call. See ETSI 

EN 300 356-1 [23] Calling Party Number signalling information. 

callingPartysCategory: 

Indicates the type of calling party (e.g. operator, pay phone, ordinary subscriber). See ETSI EN 300 356-1 [23] 

Calling Party Category signalling information. 
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locationNumber: 

This parameter is used to convey the geographical area address for mobility services, see 

ITU-T Recommendation Q.762 [44]. It is used when "callingPartyNumber" does not contain any information about 

the geographical location of the calling party (e.g., origin dependent routeing when the calling party is a mobile 

subscriber). 

originalCalledPartylD: 

If the call has met call forwarding on the route to the gsmSSF, then this parameter carries the dialled digits. Refer 

to EN 300 356-1 [23] Original Called Number signalling information. 

highLayerCompatibility: 

This parameter indicates the type of the high layer compatibility, which will be used to determine the ISDN - 
teleservice of a connected ISDN terminal. The highlayerCompatibility can also be transported by ISUP (e.g. within 
the ATP (see ITU-T Recommendation Q.763 [45]) parameter). 

additionalCallingPartyNumber: 

The calling party number provided by the access signalling system of the calling user, e.g. provided by a PBX. 

bearerCapability: 

This parameter indicates the type of the bearer capability connection or the transmission medium requirements to 

the user. It is a network option to select which of the two parameters to be used: 

bearerCap: 

This parameter contains the value of the ISUP User Service Information parameter. 

The parameter "bearerCapability" shall be included in the "InitialDP" operation only in the case the ISUP User 
Service Information parameter is available at the gsmSSF. 

If User Service Information and User Service Information Prime are available at the gsmSSF, then the 
"bearerCap" shall contain the value of the User Service Information Prime parameter. 

- eventTypeBCSM: 

This parameter indicates the armed BCSM DP event, resulting in the "InitialDP" operation. 

redirectingPartylD: 

This parameter indicates the last directory number the call was redirected from. 

redirectionlnformation: 

This parameter contains forwarding related information, such as redirecting counter. 

See ITU-T Recommendation Q.763 [45] Redirection Information signalling information. 

- iPSSPCapabilities: 

This parameter indicates which gsmSRF resources supported within the VMSC or GMSC the gsmSSF resides in 
are attached and available. 

servicelnteractionlndicatorsTwo : 

This parameter contains indicators that are used to resolve interactions between CAMEL based services and 

network based services. 

- iMSI: 

This parameter contains the IMSI of the mobile subscriber for which the service is invoked. 

subscriberState: 

This parameter indicates the state of the mobile subscriber for which the service is invoked. The possible states are 

"busy", "idle" and "not reachable". 

locationlnformation: 

This parameter indicates the location of the MS and the age of the information defining the location. 

ext-B asicS erviceCode: 

This parameter indicates the Basic Service Code. 

callReferenceNumber: 

This parameter contains the call reference number assigned to the call by the CCF. 
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msc Address: 

This parameter contains the mscld assigned to the MSC. 

gmscAddress: 

This parameter contains the gmscld assigned to the GMSC. 

calledPartyBCDNumber: 

This parameter contains the number used to identify the called party in the forward direction. It may also include 

service selection information, including * and # characters. 

time&Timezone: 

This parameter contains the time that the gsmSSF was triggered, and the time zone that the invoking gsmSSF 

resides in. 

callForwardingSS-Pending: 

This parameter indicates that a forwarded-to-number was received and that the call will be forwarded due to the 

Call Forwarding supplementary service in the GMSC or in the VMSC, unless otherwise instructed by the gsmSCF. 

carrier: 

This parameter contains carrier information. It consists of the carrier selection field followed by the Carrier ID 
information associated with the calling subscriber of a mobile originating call or trunk originating call, the called 
subscriber of a mobile terminating call or the forwarding subscriber of a mobile fowarded call. 

It contains the following embedded parameter: 

carrierSelectionField: 

This parameter indicates how the selected carrier is provided (e.g. pre-subscribed). 

carrierlD: 

This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code. 

cug-Index: 

This parameter is used to select a CUG for an outgoing call at the user, or to indicate an incoming CUG call to the 

user. 

cug-Interlock: 

This parameter uniquely identifies a CUG within a network. 

cug-OutgoingAccess: 

This parameter indicates if the calling user has subscribed to the outgoing access inter-CUG accessibility 

subscription option. 

cGEncountered: 

This parameter indicates the type of call gapping the related call has been subjected to, if any. 

cause: 

This parameter indicates the release cause which triggered the event: 

For Route_Select_Failure" it shall contain the "FailureCause", if available. 

For T_Busy it may contain the following parameters, if available. 

If the busy event is triggered by an ISUP release message, then the BusyCause shall a copy of the ISUP release 
cause, for example: Subscriber absent, 20 or User busy, 17. 

If the busy event is triggered by a MAP error, for example: Absent subscriber, received from the HLR, then the 
MAP cause is mapped to the corresponding ISUP release cause. 

If the busy event is triggered by call forwarding invocation in the GMSC or VMSC, then the BusyCause shall 
refer to the type of the call forwarding service in accordance with the mapping table in 3GPP TS 23.078 [7]. 

forwardingDestinationNumber: 

This parameter contains the forwarding destination. 

ms-Classmark2: 

This parameter contains the MS Classmark 2 of the mobile subscriber for which the service is invoked. 
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- iMEI: 

This parameter contains the IMEI (with software version) of the mobile subscriber for which the service is invoked. 

supportedCamelPhases : 

This parameter indicates the CAMEL Phases supported in the GMSC or VMSC which sends this operation. 

offeredCamel4Functionalities: 

This parameter contains the offered CAMEL phase 4 functionalities. 

bearerCapability2: 

This parameter indicates the type of the bearer capability connection or the transmission medium requirements to 

the user. 

ext-B asicS erviceCode2: 

This parameter indicates the Basic Service Code2. 

highLayerCompatibility2: 

This parameter indicates the high layer compatibility2 for a SCUDIF call. 

lowLayerCompatibility: 

This parameter indicates the low layer compatibility. 

lowLayerCompatibility2: 

This parameter indicates the low layer compatibility2 for a SCUDIF call. 

enhancedDialledServices Allowed: 

This parameter indicates that the gsmSCF may use the Enhanced Dialled Services (EDS) for this call. 

- UU-Data: 

This parameter contains user-to-user signalling service related information. 

collectlnformationAllowed: 

This parameter indicates that the gsmSCF may use Collect Information for this call. 

1 1 .20.2 Invoking entity (gsmSSF) 

1 1 .20.2.1 Normal procedure 

gsmSSF preconditions: 

(1) An event fulfilling the criteria for the DP being executed has been detected. 

(2) Call gapping and SS7 overload are not in effect for the call. 

gsmSSF postconditions: 

(1) If the DP was armed as a TDP-R and trigger conditions, if present, are fulfilled, then a control relationship 
between the gsmSCF and the gsmSSF is established. The gsmSSF FSM transits to the state 
"Waiting_for_Instructions" . 

The address of the gsmSCF shall be fetched from the valid CSI. The gsmSSF shall provide all available parameters to 
the gsmSCF. 

If no triggering takes place, because trigger conditions were not fulfilled, then the gsmSSF shall proceed with call 
handling without CAMEL Service. 

The gsmSSF application timer Tssf is loaded and started when the gsmSSF sends "InitialDP" for requesting instructions 
from the gsmSCF. It is used to prevent excessive call suspension time. 

11.20.2.2 Error handling 

If the gsmSCF is not accessible, then the call proceeds in accordance with the Default Call Handling parameter in the 
CSI. 
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When Tssf expires, then the gsmSSF shall abort the interaction with the gsmSCF by means of an abort to TC and shall 
call continue the call in accordance with the Default Call Handling parameter in the valid CSI. 

If the calling party abandons after the sending of "InitialDP" and before the TC dialogue is established, then the 
gsmSSF shall abort the interaction with the gsmSCF by means of an abort to TC. 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .21 InitiateCallAttempt procedure 

11.21.1 General Description 

The gsmSCF uses this operation to request the gsmSSF to create a new call leg to one call party using the address 
information provided by the gsmSCF (e.g. wake-up call). InitiateCallAttempt can also be used to create an additional 
call party in a new Call Segment within an existing Call Segment Association. In both use cases the gsmSCF shall 
subsequently arm 0_Answer as an EDP-R and the call failure events (Route_Select_Failure, 0_Busy and 
0_No_Answer) as EDP-Rs and/or EDP-Ns, in order to enable the gsmSCF to treat this call appropriately when any of 
these events is encountered. 

11.21.1.1 Parameters 

1 1 .21 .1 .1 .1 Argument Parameters 

destinationRouteingAddress: 

This parameter contains the called party number towards which the call shall be routed. 

callingPartyN umber: 

This parameter identifies which number shall be regarded as the calling party for the created call. 

legToBeCreated: 

This parameter indicates the LegID to be assigned to the newly created party. 

newCallSegment: 

This parameter indicates the Call Segment ID to be assigned to the newly created Call Segment. 

callReferenceN umber: 

This parameter contains the call reference number assigned to the call by the gsmSCF. 

- gsmSCFAddress: 

This parameter indicates the address of the gsmSCF initiating the operation. 

- suppress-T-CSI: 

This parameter indicates that the T-CSI for the served subscriber shall be suppressed for this call leg. 

1 1 .21 .1 .1 .2 Result Parameters 

- supportedCamelPhases: 

This parameter indicates the CAMEL Phases supported in the gsmSSF which receives this operation. 

- offeredCamel4Functionalities: 

This parameter contains the offered CAMEL phase 4 functionalities. 

11.21.2 Responding entity (gsmSSF) 
1 1 .21 .2.1 Normal procedure 

gsmSSF preconditions: 
None. 
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gsmSSF postconditions: 

1) A new O-BCSM has been created; call processing is suspended. 

2) A Return Result is sent to the gsmSCF. 

3) The CS_gsmSSF FSM transits from the state "Idle" to the state "Waiting_for_Instructions". 
All subsequent operations are treated in accordance with their normal procedures. 

11.21.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .22 MoveLeg procedure 

1 1 .22.1 General Description 

The gsmSCF uses this operation to request the gsmSSF to move the leg from its current Call Segment to CSID1. 

11.22.1.1 Parameters 

- leglDToMove: 

This parameter indicates the leg that shall be moved. 

1 1 .22.2 Responding entity (gsmSSF) 
1 1 .22.2.1 Normal procedure 

gsmSSF preconditions: 

1) A control relationship exists between the gsmSCF and the gsmSSF. 

2) The source BCSM is in the alerting phase or in the active phase. 

3) The target Call Segment fulfills the following preconditions: 

At least one leg in the target Call Segment has reached the active phase, or 

The original BCSM in the target Call Segment is at Terminating_Attempt_Authorised, Analysedjnformation 
(for EDS only) or Collected_Info detection point, and the outgoing leg of that BCSM has been disconnected by 
the gsmSCF, or 

The call was created by the gsmSCF. 

4) The CS_gsmSSF FSM for each Call Segment involved is in the state "Waiting_for_Instructions" or in the state 
"Monitoring". 

5) User Interaction is not in progress in either Call Segment. 
gsmSSF postconditions: 

1) The gsmSSF performs the appropriate call processing actions. 

2) The CS_gsmSSF FSM for CSID1 transits to the state "Waiting_for_Instructions". The BCSM instances within 
CSID1 transit to the 0_Mid_Call DP or to the T_Mid_Call DP, if not already suspended. The Mid_Call EDP shall 
not be reported for this case. 

3) The CS_gsmSSF process for the source Call Segment is terminated. 

4) A Return Result is sent to the gsmSCF immediately after successful execution of this operation. 
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5) A Pending ApplyChargingReport for the source call segment shall be sent to the gsmSCF. 

11.22.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .23 PlayAnnouncement procedure 
1 1 .23. 1 General description 

The gsmSCF uses this operation for inband interaction with a CS user. 

11.23.1.1 Parameters 

informationToSend: 

This parameter indicates an announcement a tone to be sent to the end-user by the gsmSRF. 

inbandlnfo: 

This parameter specifies the inband information to be sent. 

messagelD: 

This parameter indicates the message(s) to be sen; this may be one of the following: 

elementaryMessagelD: 

This parameter indicates a single announcement. 

text: 

This parameter indicates a text to be sent. The text shall be transformed to inband information 
(speech) by the gsmSRF. This parameter consists of two parameters; messageContent and attributes. 
The attributes of the text parameter may consist of items such as language. 

elementaryMessagelDs: 

This parameter specifies a sequence of announcements. 

variableMessage: 

This parameter specifies an announcement with one or more variable parts. 

numberOfRepetitions: 

This parameter indicates the maximum number of times the message shall be sent to the end-user. 

duration: 

This parameter indicates the maximum time duration in seconds that the message shall be played or 

repeated. A value of "0" indicates endless repetition. 

interval: 

This parameter indicates the time interval in seconds between successive messages, i.e. the time between the 
end of the announcement and the start of the repetition of this announcement. This parameter may be used 
only when "numberOfRepetitions" is > 1. 

tone: 

This parameter specifies a tone to be sent to the end-user. 

tonelD: 

This parameter indicates the tone to be sent. 

duration: 

This parameter indicates the time duration in seconds of the tone to be sent. A value of "0" indicates infinite 

duration. 

disconnectFromlPForbidden: 

This parameter indicates whether the gsmSRF may initiate a disconnection from the gsmSSF after the interaction 
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has been completed. 

If this parameter is TRUE, then the gsmSRF shall not initiate a disconnection. If this parameter is FALSE, then the 
gsmSRF may initiate a disconnection. 

requestAnnouncementCompleteNotification: 

This parameter indicates whether or not a "SpecializedResourceReport" shall be sent to the gsmSCF when all 

information has been sent. 

requestAnnouncementStartedNotification: 

This parameter indicates whether or not a "SpecializedResourceReport" shall be sent to the gsmSCF when the first 

announcement or tone has started. 

callSegmentID: 

This parameter indicates the Call Segment to which the user interaction shall apply. 

1 1 .23.2 Responding entity (gsmSRF) 

1 1 .23.2.1 Normal procedure 

gsmSRF preconditions: 

(1) The SRSM-FSM is in the state "Connected"; if the gsmSRF received previously an operation from the gsmSCF, 
then the SRSM-FSM is in the state "User Interaction". 

(2) When the first announcement or tone has started and "RequestAnnouncementStartedNotification" is TRUE, then 
the SRSM shall send a "SpecializedResourceReport" operation, containing the "FirstAnnouncementStarted" 
parameter, to the gsmSCF. 

gsmSRF postconditions: 

(1) The gsmSRF sends the information to the user as indicated by "informationToSend". 

(2) The SRSM-FSM transits to the state "User Interaction", or remains in the same state. 

(3) If all information has been sent and "RequestAnnouncementCompleteNotification" is TRUE, then the SRSM 
shall send a "SpecializedResourceReport" operation, containing the "AllAnnouncementsComplete" parameter, to 
the gsmSCF. 

(4) If all information has been sent and "disconnectFromlPForbidden" is FALSE, then the SRSM disconnects the 
gsmSRF from the user. 

The announcement sent to the end-user is ended in the following conditions: 

if neither "duration" nor "numberOfRepetitions" is specified, then the network specific announcement ending 
conditions shall apply; or 

if "numberOfRepetitions" is specified, when all repetitions have been sent; or 

if duration is specified, when the duration has expired. The announcement is repeated until this condition is met; 
or 

if "duration" and "numberOfRepetitions" is specified, when one of both conditions is satisfied (whichever comes 
first). 

11.23.2.2 Error handling 

If a Cancel operation is received before or during the processing of the operation, then that operation shall be cancelled 
immediately and the error "Canceled" shall be reported to the gsmSCF. 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 
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1 1 .24 Play Tone procedure 

1 1 .24.1 General description 

The gsmSCF uses this operation to instruct the gsmSSF to play tones to a leg or a Call Segment using the MSC's tone 
generator. 

If a Call Segment is indicated, then the tones shall be played to all active legs in that Call Segment. If a leg is indicated, 
then the tones shall be played to that leg only. 

11.24.1.1 Parameters 

- legOrCallSegment: 

This parameter indicates the leg or Call Segment to which the PlayTone operation shall apply. 

- bursts: 

This parameter indicates the variable sequence of tones to be played and consists of the following parameters: 

numberOfBursts: 

This parameter indicates the number of bursts that form the burstlist. 

burstlnterval: 

This parameter indicates the time interval between successive bursts in a sequence of bursts. 

numberOfTonesInBurst: 

This parameter indicates the number of tones to be played in each burst. 

toneDuration: 

This parameter indicates the time durationof a single tone in a burst. 

tonelnterval: 

This parameter indicates the time interval between successive tones in a burst. 

1 1 .24.2 Responding entity (gsmSSF) 

1 1 .24.2.1 Normal procedure 

gsmSSF preconditions: 

The gsmSSF FSM is in one of the following states: 

"Monitoring"; or 

" Waiting_for_Instructions " . 

If a Call Segment is indicated, then at least one of the legs in that Call Segment is in the active phase. 

gsmSSF postconditions: 

(1) No gsmSSF FSM state transition. 

1 1 .24.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting 
operation errors are described in clause 14. 

11.25 PromptAndCollectUserlnformation procedure 
1 1 .25. 1 General description 

The gsmSCF uses this operation to interact with a call party in order to collect information. 
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11.25.1.1 Parameters 

collectedlnfo: 

collectedDigits: 

minimumNbOfDigits : 
This parameter specifies the minimum number of valid digits to be collected. 

maximumNbOfDigits : 

This parameter specifies the maximum number of valid digits to be collected. The following applies: 

"maximumNbOfDigits" > "minimumNbOfDigits". 

endOfReplyDigit: 

This parameter indicates the digit string used to signal the end of input. 

In the case that the "maximumNbOfDigits" > "minimumNbOfDigits" the following applies: 

If "endOfReplyDigit" is not present, then the end of input is indicated: 

when the inter-digit timer expires; or 

when the number of valid digits received equals the "maximumNbOfDigits". 
If "endOfReplyDigit" is present, then the end of input is indicated: 

when the inter-digit timer expires; or 

when the end of reply digit is received; or 

when the number of valid digits received equals the "maximumNbOfDigits". 

When the end of input is reached, the collected digits are sent from gsmSRF to the gsmSCF, including the 
"endOfReplyDigit" if received by the gsmSRF. In the case the number of valid digits received is less than 
the "minimumNbOfDigits" when the inter-digit timer expires or when the end of reply digit is received, 
the input is considered to be erroneous. 

cancelDigit: 

This parameter indicates the cancel digit string that may be entered by the user to request a retry. All digits 
already received by the gsmSRF are discarded and the PromptAndCollectUserlnformation procedure is 
performed again, thus e.g. the same announcement to request user information is given to the user and 
information is collected. If this parameter is not present, then the user is not able to request a retry. 

startDigit: 

This parameter indicates the start digit string that indicates the start of the valid digits to be collected. The 
digits that are received by the gsmSRF before this start digit is received, are discarded and are not 
considered to be valid. The start digit string itself is considered to be valid digits. 

If this parameter is not present, then all received digits are considered to be valid. 

When the end of input is reached, the collected digits are sent from gsmSRF to the gsmSCF, including the 
"startDigit" if received by the gsmSRF. 

firstDigitTimeOut: 

If this parameter is present, then the first digit shall be received by the gsmSRF before first-digit timer 
expiration. If the first digit is not received before first-digit timer expiration, then the input is considered to 
be erroneous. 

If this parameter is not present, then the gsmSRF shall use a default value for the first-digit timer. 

If "startDigit" is present, then the first-digit timer shall be stopped after the start digit is received. If 
"startDigit" is not present, then the first-digit timer shall be stopped when any digit is received, except when 
the digit matches the 'cancelDigit', if present. 
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interDigitTimeOut: 

If this parameter is present, then any subsequent valid or invalid digit shall be received by the gsmSRF 

before the inter-digit timer expires. As a result of receiving a digit, the inter-digit timer is reset and restarted. 

If a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of 
received valid digits is less than "minimumNbOfDigits", then the input is considered to be unsuccessful. 

If a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of 
received valid digits is greater than "minimumNbOfDigits" and smaller than or equal to 
"maximumNbOfDigits", then the input is considered to be successful. 

If the "interDigitTimeOut" is not present, then the gsmSRF shall use a default value for the inter-digit timer. 

errorTreatment: 

This parameter defines what specific action shall be taken by the gsmSRF in the event of error conditions 

occurring. 

interruptableAnnlnd: 

If this parameter is TRUE, then the announcement shall interrupted after the first valid or invalid digit is 
received by the gsmSRF. If the announcement is interrupted, then a first-digit timer shall not apply anymore. 
However, if the announcement has not been interrupted, then the first-digit timer shall be started after the 
announcement has been finished. 

If this parameter is FALSE, then the announcement shall not be interrupted after the first digit is received by 
the gsmSRF. The received digits during the announcement are discarded and considered to be invalid. All 
other specified parameters ("minimumNbOfDigits", "maximumNbOfDigits", "endOfReplyDigit", etc.) do 
not apply before the announcement has been finished. The first-digit timer shall be started after the 
announcement has been finished. 

voicelnformation: 
If this parameter is FALSE, then all valid or invalid digits shall be entered by DTMF. 

If this parameter is TRUE, then the calling user is required to provide all valid or invalid information by 
speech. The gsmSRF shall perform voice recognition and shall translate the provided information into digits. 
The end of reply digit(s), if required, shall be provided by speech. 

voiceBack: 

If this parameter is FALSE, then no voice back information shall be given by the gsmSRF. 

If this parameter is TRUE, then the valid input digits received by the gsmSRF shall be announced back to 
the calling user immediately after the end of input is received. The invalid input digits will not be announced 
back to the calling user. The end of reply digit(s) shall not be voiced back to the calling user. 

disconnectFromlPForbidden: 

This parameter indicates whether the gsmSRF may initiate a disconnection from the gsmSSF after the interaction 

has been completed. 

If this parameter is TRUE, then the gsmSRF shall not initiate a disconnection. If this parameter is FALSE, then the 
gsmSRF may initiate a disconnection. 

informationToSend: 

This parameter indicates an announcement or tone to be sent to the end-user by the gsmSRF. 
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inbandlnfo: 

This parameter specifies the inband information to be sent. 

messagelD: 

This parameter indicates the message(s) to be sent;, this may be one of the following: 

elementaryMessagelD: 

This parameter indicates a single announcement. 

text: 

This parameter indicates a text to be sent. The text shall be transformed to inband information 

(speech) by the gsmSRF. The attributes of text may consist of items such as language. 

elementaryMessagelDs: 

This parameter specifies a sequence of announcements. 

variableMessage: 

This parameter specifies an announcement with one or more variable parts. 

numberOfRepetitions: 

This parameter indicates the maximum number of times the message shall be sent to the end-user. 

duration: 

This parameter indicates the maximum time duration in seconds that the message shall be played or 

repeated. A value of "0" indicates endless repetition. 

interval: 

This parameter indicates the time interval between successive messages, i.e. the time between the end of the 
announcement and the start of the repetition of this announcement. This parameter may be used only when 
"numberOfRepetitions " > 1. 

tone: 

This parameter specifies a tone to be sent to the end-user. 

tonelD: 

This parameter indicates the tone to be sent. 

duration: 

This parameter indicates the time duration in seconds of the tone. A value of "0" indicates infinite duration. 

requestAnnouncementStartedNotification: 

This parameter indicatewhether or not a "SpecializedResourceReport" shall be sent to the gsmSCF when the first 

announcement or tone has started. 

callSegmentID: 

This parameter indicates the Call Segment to which the user interaction shall apply. 

Result Parameter: 

digitsResponse: 

This parameter contains the information collected from the end-user. 

1 1 .25.2 Responding entity (gsmSRF) 
1 1 .25.2.1 Normal procedure 

gsmSRF preconditions: 

(1) The SRSM-FSM is in the state "Connected"; if the gsmSRF received previously an operation from the gsmSCF, 
then the SRSM-FSM is in the state "User Interaction". 

(2) If the first announcement or tone has started and "RequestAnnouncementStartedNotification" is TRUE, then the 
SRSM sends a "SpecializedResourceReport" operation, containing the "FirstAnnouncementStarted" parameter, 
to the gsmSCF. 
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gsmSRF postconditions: 

(1) The gsmSRF has sent the information to the end-user as indicated by "informationToSend". 

(2) The collected information from the end-user is sent to the gsmSCF as RETURN RESULT of the 
"PromptAndCollectUserlnformation". 

(3) If the "disconnectFromlPForbidden" is FALSE, then the gsmSRF initiates a bearer channel disconnect to the 
gsmSSF and the SRSM FSM transits to the state "Idle". 

(4) Otherwise, the SRSM FSM transits to the state "User Interaction" or remains in the same state. 

The announcement sent to the end-user is ended in the following conditions: 

if neither "duration" nor "numberOfRepetitions" is specified, then the network specific announcement ending 
conditions shall apply; or 

if "numberOfRepetitions" is specified, when all repetitions have been sent; or 

if duration is specified, when the duration has expired. The announcement is repeated until this condition is met; 
or 

if "duration" and "numberOfRepetitions" is specified, when one of both conditions is satisfied (whichever comes 
first). 

If the parameter "interruptableAnnlnd" is not FALSE and the end-user has responded with a digit during the sending of 
the announcement, then the above conditions are overruled. In that case, the announcement shall be ended immediately. 

The parameter "errorTreatment" specifies how the gsmSRF shall treat an error. The value "reportErrorToSCF" means 
that the error shall be reported to the gsmSCF by means of Return Error with "ImproperCallerResponse". The value 
"help" indicates that no error shall be reported to gsmSCF but assistance shall be given to the end-user in the form of a 
network dependent default announcement (which may be dependent on the context, i.e. the sent message). The value 
"repeatPrompt" indicates that no error shall be reported to the gsmSCF but the prompt shall be repeated to the end-user. 
The error handling procedures related to "help" and " repeatPrompt" shall be done only once per 
"PromptAndCollectUserlnformation" operation. 

NOTE Note on processing "endOflnput" 

The receipt of any "endOflnput" condition (e.g endOfReplyDigit, cancelDigit, firstDigitTimeout, interDigitTimeout) 

terminates immediately the ongoing input. In other words when e.g an endOfReplyDigit is received, then the 
receipt of a subsequent cancelDigit will not be processed anymore. 

11.25.2.2 Error handling 

If a Cancel operation is received before or during the processing of the operation, then the operation shall be cancelled 
immediately and the error "Canceled" shall be reported to the gsmSCF. 

Generic error handling for the operation related errors are described in clause 10, the TC services which are used for 
reporting operation errors are described in clause 14. 

If any of the parameter restrictions are violated (e.g. "minimumNbOfDigits" > "maximumNbOfDigits"), then an 
operation error has occured. 
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1 1 .26 ReleaseCall procedure 

1 1 .26. 1 General description 

The gsmSCF uses this operation to tear down a call at any phase. 

11.26.1.1 Parameters 

releaseCause: 

This parameter gives an indication to the gsmSSF about the reason of releasing this specific call. This may be 
used by gsmSSF for generating specific tones to the different parties in the call or to fill in the "cause" in the 
release message. 

1 1 .26.2 Responding entity (gsmSSF) 

1 1 .26.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between gsmSCF and gsmSSF. 

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 

gsmSSF postconditions: 

(1) The gsmSSF FSM transits to the state "Idle" after sending any pending "CalllnformationReport" or 

"ApplyChargingReport". All armed EDPs shall be disarmed. All connections and resources related to the call 
shall be released. 

11.26.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

1 1 .27 RequestReportBCSMEvent procedure 
1 1 .27.1 General description 

The gsmSCF uses this operation to request the gsmSSF to monitor for a call-related event (e.g., BCSM events such as 
0_Busy or 0_No_Answer) and to send a notification to the gsmSCF when the event is detected. 

The monitoring of more than one event may be requested with a single "RequestReportBCSMEvent" operation, but 
each of these requested events will be reported in a separate "EventReportBCSM" operation. 

NOTE: If the RequestReportBCSMEvent requests arming of the current DP from which the call processing was 
suspended, then the next occurrence of the DP encountered during BCSM processing will be detected (i.e. 
not the current one from which the call was suspended). 

The DP arming principle is as follows: 

The DPs 0_Disconnect and T_Disconnect can be armed for any or all legs depending on the direction for which 
events have to be captured. As an example, the 0_Disconnect DP can be armed for legl and leg2; in this case, if 
a release request is received from the A-party, then it will be detected by the 0_Disconnect DP armed for legl, 
while a release request from the B-party will be detected by the 0_Disconnect DP armed for leg2. 

The 0_Abandon DP can be armed only for legl in the O-BCSM and the T_Abandon DP can be armed only for 
legl in the T-BCSM. 

The Collected_Info DP can be armed only for legl in the O-BCSM for TO calls. 
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Table 11-1: DP Arming Table for O-BCSM: 



O-BCSM 


Ieg1 


Not leg 1 


Default.leg.ID 


Term Seized DP 


- 


X 


2 


Route Select Failure DP 


- 


X 


2 


Busy DP 


- 


X 


2 


No Answer DP 


- 


X 


2 


Answer DP 


- 


X 


2 


Disconnect DP 


X 


X 


/note l) 


O Abandon DP 


X 


- 




O Mid Call 


X 


- 




O Change Of Position 


X 


- 




O Service Change 


X 


- 




Collected Info DP 


X 


- 




Note 1 : The "legID" parameter shall be included 
Nomenclature: X = Arming Applicable 

- = Arming not Applicable 



Table 11-2: DP Arming Table for T-BCSM: 



T-BCSM 


Ieg2 


Ieg1 


Default Leg ID 


Call Accepted DP 


X 


- 


2 


T Busy DP 


X 


- 


2 


T No Answer DP 


X 


- 


2 


T Answer DP 


X 


- 


2 


T_Disconnect DP 


X 


X 


. (notel) 


T_Abandon DP 


- 


X (note 2) 


1 


T Mid Call 


X 


- 


2 


T Change Of Position 


X 


- 


2 


T Service Change 


X 


- 


2 


Note 1 : The "legID" parameter shall be included 
Note 2: T_Abandon can be armed for Ieg1 only. 
Nomenclature: X = Arming Applicable 

- = Arming not Applicable 



11.27.1.1 Parameters 

bcsmEvents: 

This parameter specifies the event or events of which a report is requested. 

- eventTypeBCSM: 

This parameter specifies the type of event of which a report is requested. 

monitorMode: 

This parameter indicates how the event shall be reported. If the "monitorMode" is "interrupted", then the event 
shall be reported as a request; if the "monitorMode" is "notify AndContinue", then the event shall be reported as 
a notification; if the "monitorMode" is "transparent", then the event shall not be reported. 

- legID: 

This parameter indicates the party in the call for which the event shall be reported. The gsmSCF shall use the 
option "sendingSidelD" only. 

sendingSidelD: 

If not included, then the default values for LegID are assumed according to the tables 11-1 and 1 1-2. 

The "legID" parameter shall always be included for the events 0_Disconnect and T_Disconnect. 

dPSpecificCriteria: 

This parameter contains information specific to the EDP that shall be armed. 
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numberOfDigits: 

This parameter indicates the number of digits requested for the Collectedlnfo event. 

interDigitTimeout: 

This parameter indicates the inter-digit timer value for the Collectedlnfo event. 

applicationTimer: 

This parameter indicates the No_Answer timer value for the No_Answer event. If the called party does not 
answer the call within the allotted time, then the gsmSSF shall report the event to the gsmSCF. This timer 
shall be shorter than the network No_Answer timer. 

midCallControlInfo: 

This parameter defines the criterion for the detection and reporting of mid-call digits. If this parameter is 

absent, then the first digit entered shall be reported. 

changeOfPositionControlInfo: 

This parameter defines the criterion for the reporting of change of location. If this parameter is absent, then 

any change of position shall be reported. 

automaticRearm: 

This parameter indicates that the gsmSSF shall rearm the DP whenever it is encountered. 

1 1 .27.2 Responding entity (gsmSSF) 

1 1 .27.2.1 Normal procedure 

gsmSSF preconditions: 

(1) A control relationship exists between the gsmSSF and the gsmSCF. 

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 

NOTE: In the state "monitoring" only requests to disarm detection points (with MonitorMode set to 

"Transparent") or to send notifications of events (with MonitorMode set to "Notify AndContinue") shall 
be accepted by the gsmSSF. 

gsmSSF postconditions: 

(1) The requested EDPs are armed or disarmed as indicated. 

(2) Previously requested events are monitored until ended by a transparent monitor mode, until the end of the call, 
until the EDPs are detected or until the corresponding leg is released. 

(3) The gsmSSF FSM remains in the same state, unless all EDPs have been disarmed and no CalllnformationReport 
or ApplyChargingReport has been requested; in the latter case, the gsmSSF FSM transits to the state "Idle". 

11.27.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .28 ResetTimer procedure 
1 1 .28. 1 General description 

The gsmSCF uses this operation to refresh the Tssf application timer, in order to avoid the Tssf time-out at the gsmSSF. 

11.28.1.1 Parameters 

timerlD: 

This parameter indicates which timer shall be reset. The only permissible value of this parameter is "tssf. 
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timerValue: 

This parameter specifies the value to which the timer shall be set. 

callSegmentID: 

This parameter indicates the Call Segment in the gsmSSF for which the timer shall be reset. 

1 1 .28.2 Responding entity (gsmSSF) 

1 1 .28.2.1 Normal procedure 

gsmSSF preconditions: 

(1) Basic call processing has been suspended at a DP. 

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions", the state "Waiting_for_end_of_User_Interaction" 
or in the state "Waiting_for_end_of_Temporary_Connection". 

gsmSSF postconditions: 

(1) The Tssf timer is loaded with the value received from the gsmSCF and is restarted. 

(2) No gsmSSF FSM state transition. 

11.28.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .29 SendCharginglnformation procedure 
1 1 .29. 1 General description 

The gsmSCF uses this operation to instruct the gsmSSF on the Advice of Charge information to be sent by the gsmSSF. 
The SendCharginglnformation operation may be invoked on multiple occasions. 

The SendCharginglnformation operation may be used for MO and MT calls in the VMSC. In the case of an MT call, the 
CSE provided e-parameters are not used by Mobile Station if a call forwarding or follow-on call occurs. 

11.29.1.1 Parameters 

sCIBillingChargingCharacteristics: 

This parameter is a choice between two lists of information. 

The first list shall be sent only if there is neither an active call leg, nor a Temporary Connection, nor a connection 
to a gsmSRF. It contains the following parameters: 

aOCBeforeAnswer: 

This is a list of the following information: 

aOCInitial: 

This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2] These CAI 
elements shall be sent by the gsmSSF to the MS when Answer is detected and a tariff switch for the "CSE 
control of e-parameters" has not yet occurred. 
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aOCSubsequent: 

This list may contain the following information: 

cAIElements: 

This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2]. These 
CAI elements shall be sent to the MS when Answer is detected and a tariff switch for the "CSE 
control of e-parameters" has occurred previously, or when Answer has previously been detected and a 
tariff switch for the "CSE control of e-parameters" occurs. 

tariffs witchlnterval (for the "CSE control of e-parameters"): 

This parameter indicates the time duration until the next tariff switch for the "CSE control of e- 
parameters". The measurement of the elapsed tariff switch period shall start immediately after 
successful execution of this operation. 

The second list in the choice shall be sent only if there is an active call leg or a Temporary Connection or a 
connection to a gsmSRF. It contains the following parameters: 

aOCAfterAnswer: 

This list may contain the following information: 

cAIElements: 

This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2]. These CAI 
elements shall be sent to the MS by the gsmSSF when Answer is detected and a tariff switch for the "CSE 
control of e-parameters" has occurred previously, or when Answer has previously been detected and a tariff 
switch for the "CSE control of e-parameters" occurs. 

tariffSwitchlnterval (for the "CSE control of e-parameters"): 

This parameter indicates the time duration until the next tariff switch for the "CSE control of e-parameters". 
The measurement of the elapsed tariff switch period shall start immediately after successful execution of 
this operation. 

- legID: 

This parameter indicates where the charging information shall be sent. For Mobile Originated calls, only leg 1 shall 
be used. For Mobile Terminated calls in the VMSC, only the leg of the CAMEL subscriber shall be used. 

1 1 .29.2 Responding entity (gsmSSF) 
1 1 .29.2.1 Normal procedure 

gsmSSF preconditions: 

(1) The gsmSSF FSM is in one of the following states: 

"Waiting_for_Instructions"; or 

" Waiting_for_end_of_User_Interaction" ; or 

"Waiting_for_end_of_Temporary_Connection" ; or 

"Monitoring". 

gsmSSF postconditions: 

(1) No gsmSSF FSM state transition. 

On receipt of this operation the gsmSSF performs actions to send the Advice of Charge information to the indicated 
CallPartysMS. 

If Advice of Charge shall be provided to a MS in conjunction with "CSE control of call duration", then the following 
sequence of operations may be sent by the gsmSCF to the gsmSSF in the following order, in the same TC-CONTINUE 
TC message: 

one or more ApplyCharging operations; SendCharginglnformation operation. 

These operations shall be processed sequentially by the gsmSSF, in the order that they are sent by the gsmSCF. In this 
case, the parameters TariffSwitchlnterval (for the "CSE control of call duration") may be present in any of the 
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ApplyCharging operations and the parameter TariffSwitchlnterval (for the "CSE control of e-parameters") maybe 
present in the SendCharginglnformation operation. 

The TariffSwitchlnterval information received with the ApplyCharging operation shall set or overwrite the tariff switch 
timer for the "CSE control of call duration" in the gsmSSF and this duration timer shall run from the time of successful 
operation execution. 

The TariffSwitchlnterval information received in the SendCharginglnformation operation shall set or overwrite the 
tariff switch timer for the "CSE control of e-parameters" in the gsmSSF and this duration timer shall run from the time 
of successful operation execution. 

11.29.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 1 .30 SpecializedResourceReport procedure 

1 1 .30. 1 General description 

The gsmSRF uses this operation as a response to a "Play Announcement" operation or a 
"PromptAndCollectUserlnformation" operation. This operation shall be used only when the 

"requestAnnouncementCompleteNotification" parameter is TRUE or the "requestAnnouncementStartedNotification" 
parameter is TRUE in the "Play Announcement" operation or the "PromptAndCollectUserlnformation". 

11.30.1.1 Parameters 

allAnnouncementsComplete: 

This parameter indicates that all the announcements and tones are complete. 

firstAnnouncementStarted: 

This parameter indicates that the first announcement or tone has started. 

1 1 .30.2 Invoking entity (gsmSRF) 
1 1 .30.2.1 Normal procedure 

gsmSRF preconditions: 

(1) The gsmSRF FSM is in the state "User_Interaction". 

(2) Either: 

(i) The sending of announcments and tones as defined in the "Play Announcement" operation or the 
"PromptAndCollectUserlnformation" operation has started and the parameter 
"RequestAnnouncementStartedNotification" in the "Play Announcement" or 
"PromptAndCollectUserlnformation" operation is TRUE; or 

(ii) A "Play Announcement" operation has been executed, all announcements and tones have been sent and the 
parameter "RequestAnnouncementCompleteNotification" in the Play Announcement" operation is TRUE. 

gsmSRF postconditions: 

(1) No gsmSRF FSM state transition. 

(2) If the "DisconnectFromlPForbidden" parameter is FALSE, then the gsmSRF initiates a bearer channel 
disconnect sequence to the gsmSSF using the applicable bearer channel signalling system after sending the 
"SpecializedResourceReport" operation to the gsmSCF. The gsmSRF transits to the state "Idle". 
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11.30.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

11.31 SplitLeg Procedure 

11.31.1 General Description 

The gsmSCF uses this operation to request the gsmSSF to separate one party from the source Call Segment and place it 
in a new target Call Segment. 

11.31.1.1 Parameters 

- legToBeSplit: 

This parameter indicates the party in the call to be split from the source Call Segment. 

newCallSegment: 

This parameter indicates the CSID to be assigned to the newly-created Call Segment. 

11.31.2 Responding entity (gsmSSF) 

1 1 .31 .2.1 Normal procedure 

gsmSSF preconditions: 

1) A control relationship exists between the gsmSCF and the gsmSSF. 

2) The CSID1 is either the source Call Segment or the target Call Segment. 

3) When SplitLeg is used to move a leg into CSID1 (when CSID1 does not exist), then the BCSM for the leg to be 

split shall be in the alerting phase or in the active phase. 

When SplitLeg is used to split a leg off from CSID1 into a new Call Segment, then the BCSM for the leg to be 
split shall be in the active phase. 

4) User interaction is not in progress in the source Call Segment. 
gsmSSF postconditions: 

1) The gsmSSF performs the necessary actions to separate the specified leg from its original Call Segment and place it 
in a new target Call Segment. 

2) The CS_gsmSSF FSM for the new Call Segment transits to the state "Waiting_for_Instructions". 

3) The CS_gsmSSF FSM for the source Call Segment transits to the state "Waiting_for_lnstructions". 

4) The remaining BCSM instances within the source Call Segment transit to the 0_Mid_Call DP or to the 
T_Mid_Call DP, unless already suspended at a DP. The Mid_Call EDP shall not be reported for this case. 

5) A Return Result shall be sent to the gsmSCF immediately after successful execution of this operation. 

6) A pending ApplyChargingReport for the source call segment shall be sent to the gsmSCF. 

11.31.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for 
reporting operation errors are described in clause 14. 
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1 2 Detailed operation procedures for SMS control 

NOTE: For Short Message processing in a Circuit Switched network, the CAMEL interaction with SMS is done 
through the MSC/smsSSF. 

For Short Message processing in a Packet Switched network, the CAMEL interaction with SMS is done 
through the SGSN/smsSSF. 

Any reference to the smsSSF applies to both the smsSSF co-located with the MSC and the smsSSF co- 
located with the SGSN. 

NOTE Where a parameter for an SMS control Operation is marked OPTIONAL in ASN.l, the reader is referred 
to the conditions for presence for this parameter, specified in the respective Information Flow in 3GPP 
TS 23.078 [7]. 

12.1 ConnectSMS procedure 

12.1.1 General description 

The gsmSCF uses this operation to request the smsSSF to continue Short Message processing, such as routeing a Short 
Message to a specific destination or delivering a Short Message to the served subscriber, with modified information. 

12.1.1.1 Parameters 

callingPartysNumber: 

This parameter allows the gsmSCF to set the Calling Party Number parameter used in the network. It is used for 

showing the sending party's id (i.e. the originating address) to the receiving party. 

destinationSubscriberNumber: 

This parameter contains the destination address to which the Short Message shall be routed by the SMSC. 

smscAddress: 

This parameter contains the Short Message Service Centre address towards which the Short Message shall be 

routed. 

12.1.2 Responding entity (smsSSF) 
12.1.2.1 Normal procedure 

smsSSF preconditions: 

(1) Mobile originating Short Message submission or Mobile terminating Short Message delivery attempt has been 
initiated. 

(2) Short Message processing has been suspended at the DP SMS_Collected_Info or at DP 
SMS_Delivery_Requested. 

(3) The smsSSF FSM is in the state "Waiting_for_Instructions". 

smsSSF postconditions: 

(1) The smsSSF performs the Short Message processing actions to route the Short Message to the specified 
destination or to deliver the Short Message to the served subscriber. 

On receipt of this operation, the smsSSF performs the following actions: 

if the callingPartysNumber, destinationSubscriberNumber or smscAddress are supplied, then these values shall 
be used for subsequent processing; 

if no EDPs have been armed, then the smsSSF FSM transits to the state "Idle". Otherwise, the smsSSF FSM 
transits to the state "Monitoring". 
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The smsSSF shall not perform any implicit arming or disarming of DPs. 
Statistic counter(s) are not affected. 

12.1.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

12.2 Continues MS procedure 

12.2.1 General description 

The gsmSCF uses this operation to request the smsSSF to proceed with processing at the DP at which it previously 
suspended processing to await gsmSCF instructions. The smsSSF continues processing without substituting new data 
from the gsmSCF. 

12.2.1.1 Parameters 

None. 

1 2.2.2 Responding entity (smsSSF) 

12.2.2.1 Normal procedure 

smsSSF preconditions: 

(1) processing has been suspended at any DP. 

(2) The smsSSF FSM is in the state "Waiting_for_Instructions". 
smsSSF postconditions: 

(1) processing continues. 

(2) The smsSSF FSM is in one of the following states: 

State "Monitoring" because at least one EDP was armed; or 
State "Idle" because no EDPs were armed. 

12.2.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

1 2.3 EventReportSMS procedure 
12.3.1 General description 

The smsSSF uses this operation to notify the gsmSCF of a short message related event previously requested by the 
gsmSCF in a RequestReporSMSEvent operation. 

12.3.1.1 Parameters 

- eventTypeSMS: 

This parameter identifies the type of event that is reported. 
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eventSpecificInformationSMS: 

This parameter contains the Short Message related information specific to the event. 

For 0_SMS_Failure it shall contain the O-SMSCause, if available. 

- For T_SMS_Failure it shall contain the T-SMSCause, if available. 

For 0_SMS_Submitted and for T_SMS_Delivery it shall be empty. 

miscCalllnfo: 

This parameter contains DP related information. 

messageType: 

This parameter indicates whether the message is a request, i.e. resulting from a RequestReportSMSEvent with 
"monitorMode" = "interrupted", or a notification, i.e. resulting from a RequestReportSMSEvent with 
"monitorMode" = "notify AndContinue". 

1 2.3.2 Invoking entity (smsSSF) 

12.3.2.1 Normal procedure 

smsSSF preconditions: 

(1) The smsSSF FSM is in the state "Monitoring"; 

(2) The smsSSF FSM proceeds to an EDP that is armed. 
smsSSF postconditions: 

(1) The smsSSF has applied implicit disarming of EDPs. 

(2) If message type was notification and there are no more EDPs armed, then the smsSSF FSM transits to the state 
"Idle". Otherwise, the smsSSF FSM transits to the state "Waiting_for_Instructions". 

12.3.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

12.4 FurnishCharginglnformationSMS procedure 
12.4.1 General description 

The gsmSCF uses this operation to send charging related information to a Logical SMS record. This Logical SMS 
record is CAMEL specific. The first FurnishCharginglnformationSMS operation leads to the generation of a Logical 
SMS record. Receipt of subsequent FurnishCharginglnformationSMS operations shall overwrite or append the contents 
of the Logical SMS record. 

12.4.1.1 Parameters 

- fCISMSBillingChargingCharacteristics: 

This parameter contains the following parameters; 

- fCIBCCC AMELsequence 1 : 

This parameter contains the following parameters; 

freeFormatData: 

This parameter contains free-format billing and/or charging characteristics. 

appendFreeFormatData: 

This parameter indicates whether previous free-format data shall be appended or overwritten. See 3GPP 

TS 23.078 [7] for details. 
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12.4.2 Responding entity (smsSSF) 

12.4.2.1 Normal procedure 

smsSSF preconditions: 

(1) The smsSSF FSM is in the state "Waiting_for_Instructions". 
smsSSF postconditions: 

(1) No smsSSF FSM state transition. 

On receipt of this operation, the smsSSF performs actions to create the Logical SMS record, if a Logical SMS record 
does not already exist, and writes the free-format information carried in the operation into the Logical SMS record. 
Subsequent FurnishCharginglnformationSMS operations received, by default, will overwrite the free-format data 
previously written in the Logical SMS record, as specified in 3GPP TS 23.078 [7]. It is also possible to append free 
format data with subsequent FurnishCharginglnformationSMS operations. 

The Logical SMS records will be associated for a given Short Message submission or Short Message delivery with one 
or more physical CDRs, as specified in 3GPP TS 32.250 [13], 3GPP TS 32.251 [14] and 3GPP TS 22.1 15 [4]. 

12.4.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 2.5 InitialDPSMS procedure 
12.5.1 General description 

The smsSSF uses this operation after detection of a TDP-R in the smsSF FSM, to request the gsmSCF for instructions 
to complete the Short Message submission to the SMSC or the Short Message delivery to the served subscriber. 

12.5.1.1 Parameters 

destinationSubscriberNumber: 

This parameter carries the ISDN number of the entity receiving the short message or the destination address of the 

destination subscriber, in an MO-SMS procedure. 

callingPartyN umber: 

In an MO-SMS procedure, this parameter carries the MSISDN of the subscriber. In an MT-SMS procedure, this 

parameter carries the address of the submitter of the short message (i.e. the originating address). 

eventType: 

This parameter indicates the armed smSSF FSM DP, resulting in the InitialDPSMS operation. 

- iMSI: 

IMSI of the mobile subscriber for whom the CAMEL service is invoked. 

locationlnformationlnMSC: 

This parameter indicates the location of the MSC of the served subscriber. This parameter shall be included only if 

the InitialDP operation is sent from the MSC. 

locationlnformationlnSGSN: 

This parameter indicates the location of the SGSN of the served subscriber. This parameter shall be included only if 

the InitialDPSMS operation is sent from the SGSN. 

serviceKey: 

This parameter indicates to the gsmSCF the requested IN service. It is used to address the required application/SLP 

within the gsmSCF; it is not for gsmSCF addressing. 
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timeAndTimeZone: 

This parameter contains the time that the smsSSF was triggered, and the time zone that the invoking smsSSF 

resides in. 

tPDataCodingScheme: 

This parameter indicates the data coding scheme of the TP -User-Data element within the TPDU. It may indicate a 

message class. The message class may indicate e.g. the originator of the Short Message. 

tPShortMessageSpecificInfo: 

This parameter contains the 1 st octet of the TPDU. Refer to 3GPP TS 23.040 [6] for a description of the various 

TPDUs. 

tPProtocolIdentifier: 

This parameter indicates the protocol used above the SM-Transfer Layer. 

tPValidityPeriod: 

This parameter indicates the length of the validity period or the absolute time of the validity period termination. 

- sMSCAddress: 

This parameter defines the address of the SMSC to which the Short Message is intended to be submitted. 

smsReferenceNumber: 

This parameter contains the SMS Reference Number assigned to the Short Message by the MSC or SGSN. 

msc Address: 

This parameter contains the E. 164 address of the MSC. It shall be present if the SMS processing takes place in the 

MSC; otherwise shall be absent. 

sgsn-Number: 

This parameter contains the Global Title of the SGSN. It shall be present if the SMS processing takes place in the 

SGSN; otherwise it shall be absent. 

ms-Classmark2: 

This parameter contains the MS Classmark 2 of the mobile subscriber for which the service is invoked. 

- gPRSMSClass: 

This parameter contains the GPRS MS capabilities of the mobile subscriber for which the CAMEL service is 
invoked. 

- iMEI: 

This parameter contains the IMEI (with software version) of the mobile subscriber for which the service is invoked. 

calledPartyN umber: 

This parameter indicates the served subscriber in an MT-SMS procedure. 

1 2.5.2 Invoking entity (smsSSF) 
12.5.2.1 Normal procedure 

smsSSF preconditions: 

(1) A Short Message submission attempt or a Short Message delivery attempt has been initiated. 

(2) An event has been detected at a DP. 

(3) For MT-SMS, the event fulfilled the criteria for the DP being executed. 
smsSSF postconditions: 

(1) A control relationship has been established and the smsSSF waits for instructions from the gsmSCF. 

The address of the gsmSCF the InitialDPSMS operation shall be sent to, shall be fetched from the MO-SMS-CSI or the 
MT-SMS-CSI. The smsSSF shall provide all available parameters to the gsmSCF. 
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A control relationship is established with the gsmSCF. The smsSSF application timer Tssf is laded with the deafult 
value and is started. It is used to prevent excessive Short Message submission or delivery suspension time. 

12.5.2.2 Error handling 

If the gsmSCF is not accessible, then the smsSSF instructs the MSC or SGSN to proceed with the Short Message 
processing in accordance with the Default SMS Handling parameter of the MO-SMS-CSI or MT-SMS-CSI. 

If Tssf expires, then the smsSSF aborts the interaction with the gsmSCF by means of an abort to TC and shall instruct 
the MSC or SGSN to proceed with the Short Message processing in accordance with the Default SMS Handling 
parameter of the MO-SMS-CSI CSI or MT-SMS-CSI. 

In the case of an MO-SMS Service, if the sending mobile party abandons after the sending of InitialDPSMS and before 
the TC dialogue is established, then the smsSSF shall abort the interaction with the gsmSCF by means of an abort to 
TC. 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 2.6 ReleaseSMS procedure 

12.6.1 General description 

The gsmSCF uses this operation to tear down a Short Message submission attempt or Short Message delivery attempt. 
The operation may be sent within a control relationship only; it is not allowed in a monitor relationship. 

12.6.1.1 Parameters 

rPCause: 

This parameter gives an indication to the smsSSF about the reason of releasing this specific Short Message. For a 
MO-SMS Service, the rPCause shall be sent to the served subscriber in the RP-ERROR RPDU. For a MT-SMS 
Service, the rPCause shall be sent to the SMS-GMSC in the RP-ERROR RPDU. 

1 2.6.2 Responding entity (smsSSF) 

12.6.2.1 Normal procedure 

smsSSF preconditions: 

(1) The smsSSF FSM is in the state "Waiting_for_Instructions". 

(2) The FSM is in DP SMS_Collected_Info or in DP SMS_Delivery_Requested. 

smsSSF postconditions: 

(1) The smsSSF FSM transits to the state "Idle". All armed EDPs shall be disarmed. All resources in the MSC or 
SGSN related to the Short Message shall be released. 

12.6.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

12.7 RequestReportSMSEvent procedure 
12.7.1 General description 

The gsmSCF uses this operation to request the smsSSF to monitor for a Short Message related event (FSM events such 
as failure, delivery or submission) and to send a notification to the gsmSCF when the event is detected. 
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The monitoring of more than one event may be requested with a single RequestReportSMSEvent operation, but each of 
these requested events will be reported in a separate EventReportSMS operation. 

12.7.1.1 Parameters 

smsEvents: 

This parameter indicates the event or events of which a report is requested. 

- eventTypeSMS: 

This parameter indicates the type of event of which a report is requested. Values SMSCollectedlnfo and 
SMSDeliveryRequested are not valid for the RequestReportSMSEvent operation. 

monitorMode: 

This parameter indicates how the event shall be reported. When the "monitorMode" is "interrupted", the event 
shall be reported as a request, if the "monitorMode" is "notify AndContinue", the event shall be reported as a 
notification, if the "monitorMode" is "transparent", then the event shall not be reported. 

12.7.2 Responding entity (smsSSF) 

12.7.2.1 Normal procedure 

smsSSF preconditions: 

(1) A control relationship exists between the smsSSF and the gsmSCF. 

(2) The smsSSF FSM is in the state "Waiting_for_Instructions". 
smsSSF postconditions: 

(1) The requested EDPs have been armed or disarmed as indicated. 

(2) Armed events are monitored until ended by a transparent monitor mode, until the occurance of the event or until 
the implicit disarming of the event. 

(3) No smsSSF FSM state transition. 

12.7.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

12.8 ResetTimerSMS procedure 
12.8.1 General description 

The gsmSCF uses this operation to refresh the Tssf application timer, in order to prevent Tssf expiry at the smsSSF. 

12.8.1.1 Parameters 

timerlD: 

This parameter indicates which timer shall be reset. The only permissible value of this parameter is "tssf. 

timerValue: 

This parameter defines the value to which the timer shall be set. 
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1 2.8.2 Responding entity (smsSSF) 

12.8.2.1 Normal procedure 

smsSSF preconditions: 

(1) Short Message processing has been suspended at a DP. 

(2) The smsSSF FSM is in the state "Waiting_for_Instructions". 
smsSSF postconditions: 

(1) The Tssf timer is loaded with the value received from the gsmSCF and is restarted. 

(2) No smsSSF FSM state transition. 

12.8.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 



1 3 Detailed operation procedures for GPRS control 

NOTE Where a parameter for a GPRS control Operation is marked OPTIONAL in ASN.l, the reader is referred to 
the conditions for presence for this parameter, specified in the respective Information Flow in 3GPP TS 

23.078 [7]. 

13.1 ActivityTestGPRS procedure 

13.1.1 General description 

The gsmSCF uses this operation to check for the continued existence of a relationship between the gsmSCF and the 
gprsSSF. If the relationship is still in existence, then the identified instance of gprsSSF will respond. If the 
ActivityTestGPRS operation timer expires, then the gsmSCF will assume that the receiving entity has failed in some 
way and will take appropriate action. This operation opens a new SS7 dialogue between gsmSCF and gprsSSF. 

13.1.1.1 Parameters 

None. 

13.1.2 Responding entity (gprsSSF) 
13.1.2.1 Normal procedure 

gprsSSF preconditions: 

(1) A relationship exists between the gsmSCF and the gprsSSF. 

(2) The gprsSSME FSM is in the state "Idle Management". 

(3) No active TC dialogue exists at the moment of receiving ActivityTestGPRS. 
gprsSSF postconditions: 

(1) The gprsSSME FSM transits to the state "Non-call Associated Treatment". 

(2) If there is a gprsSSF using the GPRS -Reference Number, then the gprsSSME FSM sends a Return Result 
"ActivityTestGPRS" to the gsmSCF. The gprsSSME FSM then returns to the state "Idle Management". 
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If there is no gprsSSF using the GPRS-ReferenceNumber, then the gprsSSME FSM will issue a U-Abort. The 
gprsSSME FSM then returns to the state "Idle Management". 

(3) The temporary TC dialogue is closed. 

If at the time of receiving ActivityTestGPRS there is an active TC dialogue for this GPRS Dialogue, then the 
gprsSSME FSM issues a U-Abort with Abort reason "overlapping-dialogue". 

13.1.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting 
operation errors are described in clause 14. 

13.2 ApplyChargingGPRS procedure 



13.2.1 General description 



The gsmSCF uses this operation for interacting with the gprsSSF function "CSE control of GPRS session or PDP 
Context duration and volume". The ApplyChargingGPRS Report operation provides the feedback from the gprsSSF to 
the gsmSCF. The charging scenarios supported by this operation are those given in 3GPP TS 22.078 [3] for "CSE 
control of GPRS session and PDP Context duration and volume". 

If this procedure is used within a PDP Context dialogue, then the charging instruction shall pertain to the PDP Context 
only. Data volume threshold and duration threshold may be defined separately. 

If this procedure is used within a GPRS Session dialogue, then the charging instruction may pertain to the GPRS 
Session or to a single PDP Context. Charging for a PDP Context may be on duration and/or volume. Charging for a 
GPRS Session may be on duration only. 

NOTE: Charging for a PDP Context on duration and volume requires two ApplyChargingGPRS operations. 

13.2.1.1 Parameters 

chargingCharacteristics: 

This parameter is a choice between parameters required for "CSE control of a GPRS session or a PDP Context 

duration or volume": 

maxTransferred Volume : 

This parameter specifies the maximum volume that may be transferred before a ApplyChargingReportGPRS 

shall be sent to the gsmSCF. 

maxElapsedTime: 

This parameter specifies the maximum period of time before a ApplyChargingReportGPRS shall be sent to 

the gsmSCF. 

tariffs witchlnterval: 

This parameter indicates the time duration until the next tariff switch. The measurement of the elapsed tariff switch 

period shall start immediately after successful execution of this operation. 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, to which the charging instruction 
applies. 



1 3.2.2 Responding entity (gprsSSF) 
13.2.2.1 Normal procedure 

gprsSSF preconditions: 
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(1) A control relationship exists between the gsmSCF and the GPRS Session or PDP Context to which the operation 
applies. 

(2) The gprsSSF FSM is in one of the following states: "Waiting_for_Instructions" or "Monitoring". 
gprsSSF postconditions: 

(1) No gprsSSF FSM state transition. 

On receipt of this operation, the gprsSSF shall set the charging data using the information elements included in the 
operation. 

13.2.2.2 Error handling 

"TaskRefused": In addition to the generic error handling noted below, this error shall be indicated when: 

a previously received GPRS Session or PDP Context period or volume duration is pending; 

a tariffSwitchlnterval is indicated when a previously received tariffs witchlnterval is pending; 

the gprsSSF has received an ApplyChargingGPRS operation for a PDP Context that is already disconnected; 

the gprsSSF has received an ApplyChargingGPRS operation for the GPRS Session when the subscriber is 
already detached. 

Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting 
operation errors are described in clause 14. 

13.3 ApplyChargingReportGPRS procedure 
13.3.1 General description 

The gprsSSF uses this operation to report charging related information to the gsmSCF as requested by the gsmSCF 
using the ApplyChargingGPRS operation. 

Timing of duration and measuring of transferred data (if applicable) shall be started when either an Attach, PDP 
Context Establishment Acknowledgement or an Inter SGSN Routeing Area Update acceptance is detected by the 
gprsSSF. 

A report shall be made when a PDP Context Disconnect, a Detach or a Change in QoS is detected by the gprsSSF or 
when the gprsSSF detects that the transferred volume or elapsed time duration indicated in the parameter 
"transferredVolume" or "elapsedTime" (received in ApplyChargingGPRS operation) has been reached. 
ApplyChargingReportGPRS shall be sent only on chargeable QoS changes. 

13.3.1.1 Parameters 

chargingResult: 

This parameter provides the gsmSCF with the charging related information previously requested using the 

ApplyChargingGPRS operation. The "ChargingResult" is a choice, and can contain either of the following 

parameters: 

transferredVolume: 

This is a choice of the following parameters: 

volumelfNoTariffS witch: 

This parameter shall be present if no tariff switch has occurred for the PDP Context, otherwise it shall be 
absent. If present, then the volume transferred since the detection of the event that triggered volume count 
shall be reported. 

volumelfTariffS witch: 

This parameter shall be present if a tariff switch has occurred for the PDP Context, otherwise it shall be 

absent. This parameter may contain the following information: 
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volumeSinceLastTariffSwitch: 

The volume since the detection of the event that triggered volume count or the last tariffSwitch 

(whichever of these events was last detected) shall be reported. 

VolumeTariffSwitchlnterval: 

This parameter shall be present only if a tariff switch was detected after the event that triggered 
volume count for the PDP Context in the current volume count period. If present, the volume between 
either the detection the event that triggered volume count or the previous tariff switch (whichever of 
these events was last detected) and the last tariff switch shall be reported. 

elapsedTime: 

This parameter is a choice of the following parameters: 

- timeGPRSIfNoTariffSwitch: 

This parameter shall be be present if no tariff switch has occurred for the GPRS Session or the PDP 
Context, otherwise it shall be absent. If present, then the elapsed time since the detection of the event that 
triggered time count shall be reported. 

- timeGPRSIfTariffSwitch: 

This parameter shall be present if a tariff switch has occurred for the GPRS Session or the PDP Context, 
otherwise it shall be absent. TThis parameter may contain the following information: 

- timeGPRSSinceLastTariffSwitch: 

The time since the event that triggered time count or the last tariffSwitch shall be reported. 

- timeGPRSTariffSwitchlnterval: 

This parameter shall be present only if a tariff switch was detected after the event that triggered time 
count for the GPRS Session or PDP Context in the current time count period. If present, then the time 
between either the detection the event that triggered time count or the previous tariff switch 
(whichever of these events was last detected) and the last tariff switch shall be reported. 

qualityOfService: 

This parameter identifies the QoS which was negotiated between the user, the SGSN and the GGSN. 

This parameter shall be present only if the sending of the ApplyChargingReportGPRS operation was triggered 

by a change in Quality of Service. The "negotiated-QoS-Extension" may be present as a supplement to the 

"negotiated-QoS". 

active: 

This parameter indicates whether the GPRS Session or PDP Context is still active 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, for which the charging report is 
valid. 

chargingRollOver: 

This parameter indicates possible rollovers of the "ChargingResult" parameter due to the limited value ranges of 
the associated charging parameters. The "chargingRollOver" parameter is a choice and may contain either of the 
following parameters: 

transferredVolumeRollOver: 

This parameter is a choice of the following parameters: 

- rO-VolumelfNoTariffSwitch: 

This parameter indicates how many times the volumelfNoTariff Switch parameter of the chargingResult 
has rolled over. If no rollover has happened, then rO-VolumelfNoTariffSwitch may be absent. 

- rO-VolumelfTariffS witch: 

This parameter is present if at least one of the parameters below is present. It may contain the following 
information: 

rO- VolumeSinceLastTariffSwitch: 

This parameter indicates how many times the volumeSinceLastTariffSwitch parameter of the 
chargingResult has rolled over. If no rollover has happened, then rO- VolumeSinceLastTariffSwitch 
may be absent. 
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rO-VolumeTariffSwitchlnterval: 

This parameter indicates how many times the VolumeTariffSwitchlnterval parameter of the 
chargingResult has rolled over. If no rollover has happened, then rO- VolumeTariffSwitchlnterval may 
be absent. 

elapsedTimeRollOver: 

This parameter is a choice of the following parameters: 

- rO-TimeGPRSIfNoTariffSwitch: 

This parameter indicates how many times the timeGPRSIfNoTariffSwitch parameter of the 
chargingResult has rolled over. If no rollover has happened, then rO-TimeGPRSIfNoTariffSwitch may be 
absent. 

- rO-TimeGPRSIfTariffSwitch: 

This parameter shall be present if at least one of the parameters below is present. If It may contain the 
following information: 

- rO-TimeGPRS S inceLastTariff S witch: 

This parameter indicates how many times the timeGPRSSinceLastTariffSwitch parameter of the 
chargingResult has rolled over. If no rollover has happened, then rO- 
TimeGPRSSinceLastTariffSwitch may be absent. 

- rO-TimeGPRSTariffSwitchlnterval: 

This parameter indicates how many times the timeGPRSTariffSwitchlnterval parameter of the 
chargingResult has rolled over. If no rollover has happened, then rO-TimeGPRSTariffSwitchlnterval 

may be absent. 

1 3.3.2 Invoking entity (gprsSSF) 

13.3.2.1 Normal procedure 

gprsSSF preconditions: 

(1) A relationship exists between the gsmSCF and the GPRS Session or PDP Context. 

(2) A charging event has been detected that was requested by the gsmSCF via an ApplyChargingGPRS operation. 
gprsSSF postconditions: 

(1) If termination of the GPRS Session or a PDP Context has occurred, then: 

If the sending of ApplyChargingReportGPRS is directly followed by the reporting of an EDP-R, then the 
gprsSSF FSM shall transit to the state "Waiting_for_Instructions"; else 

If there are any armed EDPs or pending reports, then the gprsSSF FSM shall remain in the same state; else 

If there are no armed EDPs or pending reports, then the gprsSSF FSM shall transit to the state "Idle". 

(2) If the sending of ApplyChargingReportGPRS is due to a timer or counter expiry, then: 

If there are any armed EDPs or pending reports, then the gprsSSF FSM shall remain in the same state; else 
If there are no armed EDPs or pending reports, then the gprsSSF FSM shall transit to the state "Idle". 

(3) If the sending of ApplyChargingReportGPRS is due to a change in QoS of a PDP Context, then: 

The gprsSSF FSM shall remain in the same state. 

13.3.2.2 Error handling 

If the operation timer expires, then the gprsSSF shall abort the TC dialogue, terminate the GPRS dialogue and instruct 
the SGSN to handle the GPRS session or PDP context in accordance with the default GPRS handling parameter of the 
valid CSI. 
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Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting 
operation errors are described in clause 14. 

1 3.4 CancelGPRS procedure 

13.4.1 General description 

The gsmSCF uses this operation to request the gprsSSF to disarm all pending EDPs and to cancel all pending reports for 
a GPRS Session or for a specific PDP Context. This enables the gprsSSF FSM to transit to the state "Idle". 
This procedure can not be used to cancel a previous operation. 

13.4.1.1 Parameters 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, for which the armed EDPs shall 
be disarmed and the pending reports shall be cancelled. 

13.4.2 Responding entity (gprsSSF) 

13.4.2.1 Normal procedure 

gprsSSF preconditions: 

(1) The gprsSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 
gprsSSF postconditions: 

(1) All pending ApplyChargingReportGPRS are cancelled and all pending EDPs are disarmed. If a PDPID is 
included in the operation, then the cancelling of the pending reports and the disarming of the armed events 
applies to the indicated PDP Context only. 

(2) If the gprsSSF FSM was in the state "Monitoring" and there are no more armed EDPs or pending 
ApplyChargingReportsGPRS, then the gprsSSF FSM shall transit to the state "Idle". 

If the gprsSSF FSM was in the state "Waiting_for_Instructions", it shall remain in that state. If there are no more 
armed EDPs or pendingApplyChargingReportsGPRS, then subsequent GPRS Session or PDP Context 
processing operation will result in the gprsSSF FSM to transit the state "Idle". 

The GPRS Session or PDP Context to which the CancelGPRS operation applies, if in active state, shall further 
be treated by the gprsSSF autonomously as a normal (non-CAMEL) GPRS Session or PDP Context. 

13.4.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.5 ConnectGPRS procedure 
13.5.1 General description 

The gsmSCF uses this operation to provide an APN to the gprsSSF, to be used for establishing a PDP Context. 

13.5.1.1 Parameters 

- accessPointName: 

This parameter contains the Access Point Name towards which the PDP Context shall be established. Refer to 
3GPP TS 29.060 [12] for details on the Access Point Name. 
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- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, for which the Access Point Name 
shall be used. 

13.5.2 Responding entity (gprsSSF) 

13.5.2.1 Normal procedure 

gprsSSF preconditions: 

(1) A control relationship exists between the gsmSCF and the PDP Context. 

(2) The GPRS PDP Context FSM is supsended at DP PDP_Context_Establishment. 

(3) The gprsSSF FSM is in the state "Waiting_for_Instructions". 
gprsSSF postconditions: 

(1) The gprsSSF performs the actions to establish the PDP Context using the given Access Point Name. 

(2) The gprsSSF stops Tssf. 

(3) If no EDPs are armed, then the gprsSSF FSM transits to the state "Idle". Otherwise the gprsSSF FSM transits to 
the state "Monitoring". 

The gsmSSF shall not perform any implicit arming or disarming of DPs. 

13.5.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.6 ContinueGPRS procedure 

13.6.1 General description 

The gsmSCF uses this operation to request the gprsSSF to proceed with GPRS Session or PDP Context processing at 
the DP at which it previously suspended processing to await gsmSCF instructions. The gprsSSF continues processing 
without substituting new data from the gsmSCF. 

13.6.1.1 Parameters 

- pDPID: 

This parameter identifies the PDP Context within the control relationship for which the processing shall 
continue. 

1 3.6.2 Responding entity (gprsSSF) 
13.6.2.1 Normal procedure 

gprsSSF preconditions: 

(1) A control relationship exists between the gsmSCF and the GPRS Session or PDP Context. 

(2) The GPRS Session or PDP Context processing has been suspended at any DP. 

(3) The gprsSSF FSM is in the state "Waiting_for_Instructions". 
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gsmSSF postconditions: 

(1) GPRS Session or PDP Context processing continues. 

(2) The gprsSSF FSM is in one of the following states: 

"Monitoring" because at least one EDP was armed or an ApplyChargingReportGPRS was requested; or 
"Idle" because no EDPs were armed and no ApplyChargingReportGPRS was requested. 



13.6.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

13.7 EntityReleasedGPRS procedure 

13.7.1 General description 

The gprsSSF uses this operation to inform the gsmSCF that the GPRS Session is detached or a PDP Context is 
disconnected. It shall be used only when the associated event detection point (ie. for GPRS Session Detach: DP 
"Detach" and for PDP Context Disconnect: DP "PDP Context Disconnection") is at that moment not armed for 
reporting. 

This operation shall be used irrespectively of the functional entity that initiated the Detach or PDP Context Disconnect 
and irrespectively of the cause for the Detach or PDP Context Disconnect. 

When a PDP Context is terminated, then the gprsSSF shall send all pending reports of that PDP Context to the gsmSCF. 
When a GPRS Session is terminated, then the gprsSSF shall send all outstanding reports of the GPRS Session to the 
gsmSCF. 

13.7.1.1 Parameters 

- gPRSCause: 

This parameter gives an indication to the gsmSCF about the reason for discontinuing the PDP Context or GPRS 
Session. This may be used by gsmSCF if a FurnishCharginglnformationGPRS operation needs to be sent to the 
gprsSSF. 

- pDPID: 

This parameter identifies the PDP Context within the GPRS Session dialogue, which has terminated. 

1 3.7.2 Invoking entity (gprsSSF) 

13.7.2.1 Normal procedure 

gprsSSF preconditions: 

(1) The gprsSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 

gprsSSF postconditions: 

(1) All armed EDPs for the indicated PDP Context or GPRS Session shall be disarmed. All connections and 
resources related to the indicated PDP Context or GPRS Session shall be released. 

If there are no more armed EDPs or pending reports, then the gprsSSF FSM transits to the state "Idle"; otherwise 
the gprsSSF FSM remains in the same state. 

13.7.2.2 Error handling 

If the operation timer expires, then the gprsSSF shall abort the TC dialogue, terminate the GPRS dialogue and instruct 
the SGSN to handle the GPRS session or PDP context in accordance with the default GPRS handling parameter of the 
valid CSI. 
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Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

1 3.8 EventReportGPRS procedure 
13.8.1 General description 

The gprsSSF uses this operation to notify the gsmSCF of a GPRS Session or PDP Context event previously requested 
by the gsmSCF in a RequestReportGPRSEvent operation. 

13.8.1.1 Parameters 

gPRSEventType: 

This parameter specifies the type of event that is reported. 

gPRSEventSpecificInformation: 

This parameter indicates the GPRS Session or PDP Context related information specific to the event. 

For Change of Position GPRS Session it shall contain the "locationlnformationGPRS", if available. 

For Change of Position PDP Context it shall contain the "accessPointName", "chargingID", 
"locationlnformationGPRS", "endUserAddress", Quality of Service, "timeAndTimeZone" and 
"gGSNAddress" and "secondaryPDP-context", if available. 

For Detach and PDP Context Disconnect it shall contain the "initiatingEntity" and, conditionally, 
"routeingAreaUpdate". The "initiatingEntity" indicates the entity that initiated the Detach or PDP Context 
Disconnect. The "routeingAreaUpdate" indicates that the Detach or PDP Context Disconnect is due to inter- 
SGSN routeing area update. 
In the case of inter-SGSN routeing area update, the gsmSCF may ignore the " initiatingEntity". 

For PDP Context Establishment it shall contain the "accessPointName", "endUserAddress", 
"pDPInitiationType", Quality of Service, "locationlnformationGPRS", "timeAndTimeZone" and 
"secondaryPDP-context", if available. 

The Quality of Service shall contain the Requested QoS and the Subscribed QoS. The " requested -QoS - 
Extension" and the "subscribed-QoS-Extension" may be present as supplements to the "requested-QoS" and 
the "subscribed-QoS" respectively. 

For PDP Context Establishment Acknowledgement it shall contain the "accessPointName", "chargingID" 
"endUserAddress", Quality of Service, "locationlnformationGPRS", "timeAndTimeZone" and 
"gGSNAddress", if available. 

The Quality of Service shall contain the Requested QoS, the Subscribed QoS and the Negotiated QoS. The 
"requested-QoS-Extension", the "subscribed-QoS -Extension" and the "negotiated-QoS-Extension" maybe 
present as supplements to the "requested-QoS", the "subscribed-QoS" and the "negotiated-QoS" respectively. 

All optional gPRSEventSpecificInformation parameters shall be sent in accordance with 3GPP TS 23.078 [7] 
subclause 6.6.1.4 and 3GPP TS 22.078 [3] annex "GPRS Information provided to the CSE". 

- miscGPRSInfo: 

This parameter contains DP related information. 

messageType: 

This parameter indicates whether the message is a request, i.e. resulting from a RequestReportGPRSEvent with 
"monitorMode" = "interrupted", or a notification, i.e. resulting from a RequestReportGPRSEvent with 
"monitorMode" = "notify AndContinue". 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, for which the event is reported. 
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1 3.8.2 Invoking entity (gprsSSF) 

13.8.2.1 Normal procedure 

gprsSSF preconditions: 

(1) The gprsSSF FSM is in the state "Monitoring" or in the state "WaitingForlnstructions". 

(2) The GPRS Session or PDP Context FSM proceeds to an EDP that is armed. 
gprsSSF postconditions: 

(1) If the message type was notification and there are still armed EDPs that can be met or there any pending reports, 
then the gprsSSF FSM shall remain in the state "Monitoring". 

(2) If the message type was notification and there no more EDPs armed that can be met and there are no pending 
reports, then the gprsSSF FSM shall transit to the state "Idle". 

(3) If the message type was request, then the gprsSSF FSM shall transit to the state "Waiting_for_Instructions". 
GPRS Session or PDP Context processing is interrupted. 

If an EDP-R is met that causes the release of a GPRS Session or PDP Context, then all EDPs related to the GPRS 
Session or PDP Context shall be disarmed. 

13.8.2.2 Error handling 

If the operation timer expires, then the gprsSSF shall abort the TC dialogue, terminate the GPRS dialogue and instruct 
the SGSN to handle the GPRS session or PDP context in accordance with the default GPRS handling parameter of the 
valid CSI. 

If the message type is "request" and the Tssf timer expires, then the gprsSSF shall abort the TC dialogue and shall 
instruct the SGSN to treat the GPRS Session or PDP Context in accordance with the default GPRS handling of the valid 
CSI. 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.9 FurnishCharginglnformationGPRS procedure 
13.9.1 General description 

The gsmSCF uses this operation to send charging related information to a Logical GPRS record. This Logical GPRS 
record is CAMEL specific. The first FurnishCharginglnformationGPRS operation results in the generation of a Logical 
GPRS record. Receipt of subsequent FurnishCharginglnformationGPRS operations shall overwrite or append the 
contents of the Logical GPRS record. 

13.9.1.1 Parameters 

- fCIGPRSBillingChargingCharacteristics: 

This parameter contains the following parameters; 

- fCIBCCC AMELsequence 1 : 

This parameter contains the following parameters; 

freeFormatData: 

This parameter contains free-format billing and/or charging characteristics. 

appendFreeFormatData: 

This parameter indicates whether previous FCI free format data is appended or overwritten. Refer to 

3GPP TS 23.078 [7] for details of this mechanism. 
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- pDPID: 

This parameter indicates the PDP Context's Logical GPRS record to which the free format data belongs. 

1 3.9.2 Responding entity (gprsSSF) 

13.9.2.1 Normal procedure 

gprsSSF preconditions: 

(1) The gprsSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 
gprsSSF postconditions: 

(1) No gprsSSF FSM state transition. 

On receipt of this operation the gprsSSF performs actions to create the Logical GPRS record, if necessary, and writes 
the free-format information carried in the operation into the GPRS record. A FurnishCharginglnformationGPRS 
operation will create a Logical GPRS Data Record (CDR) if such a record does not already exist. Subsequent 
FurnishCharginglnformationGPRS operations received, will either overwrite or append the data previously written in 
the free-format CDR field depending on the presence and value of the parameter "appendFreeFormatData". 

The Logical GPRS records will be associated for a given GPRS Session or PDP Context with one or more physical 
CDRs, as specified in 3GPP TS 32.250 [14] and 3GPP TS 22.1 15 [4]. 

13.9.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.10 InitialDPGPRS procedure 
13.10.1 General description 

The gprsSSF uses this operation after detection of a TDP-R in the GPRS Session or PDP Context state machine, to 
request the gsmSCF for instructions to complete the GPRS Session or PDP Context. 

For a GPRS Session, the "Attach" and "Change of Position Session" TDPs may result in the InitialDPGPRS Procedure. 

For a PDP Context, the "PDP Context Establishment", the "PDP Context Establishment Acknowledgement" and the 
"Change of Position Context" TDPs may result in the InitialDPGPRS Procedure. 

If a PDP Context related TDP is met and there is at that moment a GPRS dialogue for the GPRS Session, then the 
gprsSSF shall not initiate the InitialDPGPRS Procedure for that PDP Context. 

If the "PDP Context Establishment Acknowledgement" event occurs and this event is armed as a TDP, and there is at 
that moment a GPRS dialogue for the PDP Context, then the gprsSSF shall not initiate a new InitialDPGPRS Procedure 
for that PDP Context. 

13.10.1.1 Parameters 

serviceKey: 

This parameter indicates to the gsmSCF the requested IN service. It is used to address the required application/SLP 

within the gsmSCF; it is not used for SCP addressing. 

- gPRSEventType: 

This parameter indicates the armed GPRS Attach/Detach FSM or PDP Context FSM DP event, resulting in the 
InitialDPGPRS operation. 

- mSISDN: 

This parameter contains the MSISDN of the mobile subscriber for which the CAMEL service is invoked. 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 181 ETSI TS 129 078 V8.2.1 (2010-04) 

- iMSI: 

This parameter contains the IMSI of the mobile subscriber for which the CAMEL service is invoked. 

timeAndTimezone: 

This parameter contains the time that the gprsSSF is triggered, and the time zone that the invoking gprsSSF resides 

in. 

- gPRSMSClass: 

This parameter contains the MS capabilities of the mobile subscriber for which the CAMEL service is invoked. 

endUserAddress: 

This parameter identifies the PDP type, PDP type organisation and the actual PDP address. 

qualityOfService: 

This parameter contains the Quality of Service. 

If the InitialDPGPRS operation is sent as a result of the "PDP Context Establishment" TDP, then the Quality of 

Service parameter shall contain the Requested QoS and the Subscribed QoS. The "requested-QoS-Extension" and 

the "subscribed-QoS -Extension" may be present as supplements to the "requested-QoS" and the "subscribed-QoS" 

respectively. 

If the InitialDPGPRS operation is sent as a result of the "PDP Context Establishment Ackonwledgement" TDP or 

the Change of Position Context TDP, then the Quality of Service parameter shall contain the Requested QoS, the 

Subscribed QoS and the Negotiated QoS. The "requested-QoS -Extension", the "subscribed-QoS-Extension" and the 

"negotiated-QoS-Extension" may be present as supplements to the "requested-QoS", the "subscribed-QoS" and the 

"negotiated-QoS" respectively. 

accessPointName: 

This parameter contains the requested address that the MS for which the CAMEL service is invoked for wants to 

connect to. 

routeingArealdentity: 

This parameter contains the location information of the MS for which the CAMEL service is invoked. 

chargingID: 

This parameter contains the charging ID that, together with the gGSNAddress, uniquely identifies the PDP Context 

for the MS for which the CAMEL service is invoked. 

sGSNcapabilities: 

This parameter specifies the capabilities which the SGSN node can provide for the CAMEL service control. 

locationlnformationlnSGSN: 

This parameter indicates the location of the sending MS. 

pDPInitiationType: 

This parameter indicates whether a PDP Context was established as a result of a network-initiated request or as a 

result of a subscriber request. 

- gGSNAddress: 

This parameter refers to the IP address of the GGSN where the PDP Context terminates. It is used together with the 
chargingID for uniquely identification of the PDP Context for which the CAMEL service is invoked from. 

secondaryPDP-context: 

This parameter indicates that the PDP Context is requested as a secondary PDP Context. 

- iMEI: 

This parameter contains the IMEI (with software version) of the mobile subscriber for which the service is invoked. 

1 3.1 0.2 Invoking entity (gprsSSF) 
13.10.2.1 Normal procedure 

gprsSSF preconditions: 

(1) An event has been met that is armed as TDP. 
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(2) There is no GPRS dialogue active for that PDP Context or for the GPRS Session. 
gprsSSF postconditions: 

(1) A control relationship is established between the gsmSCF and the GPRS Session or the PDP Context. 

(2) The gprsSSF FSM is in the state "Waiting_for_Instructions". 

The address of the gsmSCF that the InitialDPGPRS operation shall be sent to, shall be fetched from the valid CSI. The 
gprsSSF shall provide all available parameters to the gsmSCF. 

The gprsSSF application timer Tssf shall be loaded and started when the gprsSSF sends InitialDPGPRS for requesting 
instructions from the gsmSCF. It is used to prevent excessive GPRS Session or PDP Context duration or volume usage. 

13.10.2.2 Error handling 

If the gsmSCF is not accessible, then the gprsSSF instructs the SGSN to handle the GPRS Session or PDP Context in 
accordance with the Default GPRS Handling parameter of the valid CSI. 

If Tssf expires, then the gprsSSF shall abort the interaction with the gsmSCF by means of an abort to TC and shall 
instruct the SGSN to handle the GPRS Session or PDP Context in accordance with the Default GPRS Handling 
parameter of the valid CSI. 

If the MS abandons the establishment of a GPRS Session or PDP Context after the sending of InitialDPGPRS and 
before the TC dialogue is established, then the gprsSSF shall abort the interaction with the gsmSCF by means of an 
abort to TC. 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.11 ReleaseGPRS procedure 

13.11.1 General description 

The gsmSCF uses this operation to tear down by the gsmSCF an existing GPRS Session or PDP Context at any phase. 

13.11.1.1 Parameters 

- gPRSCause: 

This parameter gives an indication to the gprsSSF about the reason of releasing the GPRS Session or a specific 
PDP Context. This may be used by gprsSSF for generating specific indications to the MS or to fill in the "cause" 
in the release message. 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, which shall be released. 

13.11.2 Responding entity (gprsSSF) 
13.11.2.1 Normal procedure 

gprsSSF preconditions: 

(1) A control relationship exists between gsmSCF and the GPRS Session or PDP Context. More specifically, in 
order to tear down an individual PDP Context, an EDP-R must be armed for that PDP Context. In order to make 
a SCP controlled detach an EDP-R must be armed for the GPRS Session. 

(2) The gprsSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 
gprsSSF postconditions: 

(1) All pending reports for the GPRS Session or the PDP Context shall be reported to the gsmSCF. 
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(2) All connections and resources related to the GPRS Session or the PDP Context shall be released. 

(3) All armed EDPs for the GPRS Session or the PDP Context shall be disarmed. 

(4) If there are no more pending reports or armed events, then the gprsSSF FSM transits to the state "Idle". 

If there are any pending reports or armed events, then the gprsSSF FSM remains in the same state. 

13.11.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.12 RequestReportGPRSEvent procedure 

13.12.1 General description 

The gsmSCF uses this operation to request the gprsSSF to monitor for a GPRS Session or PDP Context related event 
(e.g., events such as PDP Context establishment or detach) and to send a notification to the gsmSCF when the event is 
detected. 

The monitoring of more than one event may be requested with a single RequestReportGPRSEvent operation, but each 
of these requested events will be reported in a separate EventReportGPRS operation. 

13.12.1.1 Parameters 

- gPRSEvent: 

This parameter specifies the event or events of which a report is requested. 

- gPRSEventType: 

This parameter specifies the type of event of which a report is requested. 

monitorMode: 

This parameter indicates how the event shall be reported. If the "monitorMode" is "interrupted", then the 
event shall be reported as a request; if the "monitorMode" is "notify AndContinue", then the event shall be 
reported as a notification; if the "monitorMode" is "transparent", then the event shall not be reported. 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, for which the event reporting is 
requested 

1 3. 1 2.2 Responding entity (gprsSSF) 
13.12.2.1 Normal procedure 

gprsSSF preconditions: 

(1) A control relationship exists between the gsmSCF and the GPRS Session or PDP Context. 

(2) The gprsSSF FSM is in the state "Waiting_for_Instructions" or the state "Monitoring". 

In the state "monitoring" only requests to disarm detection points (with MonitorMode set to "Transparent") or send 
notifications of events (with MonitorMode set to "Notify AndContinue") shall be accepted. 

gprsSSF postconditions: 

(1) The requested EDPs have been armed or disarmed as indicated. 

(2) Previously requested events are monitored until ended by a transparent monitor mode, until the end of the GPRS 
Session or PDP Context or until the EDPs are detected. 
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(3) If there sare no armed events or pending reports, then the gsmSSF FSM shall transit to the state "Idle". 
Otherwise it shall remain in the same state. 

13.12.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.13 ResetTimerGPRS procedure 

13.13.1 General description 

The gsmSCF uses this operation to refresh the Tssf application timer, in order to avoid the Tssf time-out at the gprsSSF. 

13.13.1.1 Parameters 

timerlD: 

This parameter indicates which timer shall be reset. The only permissable value for this parameter is "Tssf". 

timerValue: 

This parameter specifies the value to which the timer shall be set. 

1 3. 1 3.2 Responding entity (gprsSSF) 

13.13.2.1 Normal procedure 

gprsSSF preconditions: 

(1) GPRS Session or PDP Context processing has been suspended at a DP. 

(2) The gprsSSF FSM is in the state "Waiting_for_Instructions". 
gprsSSF postconditions: 

(1) The Tssf timer is loaded with the value received from the gsmSCF and is restarted. 

(2) No gprsSSF FSM state transition. 

13.13.2.2 Error handling 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 

13.14 SendCharginglnformationGPRS Procedure 
13.14.1 General description 

The gsmSCF uses this operation to instruct the gprsSSF on the Advice of Charge information to be sent to the MS, 
provided that the SGSN supports Advice of Charge. The operation may be invoked on multiple occasions. 

13.14.1.1 Parameters 

sCIGPRSBillingChargingCharacteristics: 

This parameter contains the Advice of Charge information: 

- aOCGPRS: 

This parameter specifies the Advice of Charge information that shall be sent to the MS. It may contain one or 
more of the following parameters: 
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aOCInitial: 

This is a set of Charge Advice Information elements, as defined in 3GPP TS 22.024 [2]. These CAI 
elements shall be sent by the gprsSSF to the MS when an Activate PDP Context Accept or Attach Accept 
is sent to MS and a tariff switch has not yet occurred. It may also be sent at any other time e.g. upon 
change of QoS or RAI. 

aOCSubsequent: 

This parameter may contain the following information: 

cAIElements: 

This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2]. These 
CAI elements shall be sent to the MS when an Activate PDP Context Accept or Attach Accept is 
detected and a tariff switch has occurred previously, or when Activate PDP Context Accept or Attach 
Accept has previously been detected and a tariff switch occurs. 

tariffs witchlnterval: 

This parameter indicates to the gprsSSF the time duration until the next tariff switch. The 
measurement of the elapsed tariff switch period shall start immediately after successful execution of 
this operation. 

- pDPID: 

This parameter identifies the PDP Context, within the GPRS Session dialogue, for which the Advice-of-Charge 
instruction applies. 

13.14.2 Responding Entity (gprsSSF) 

13.14.2.1 Normal Procedure 

gprsSSF preconditions: 

(1) A relationship exists between the gsmSCF and the GPRS Session or PDP Context. 

(2) The gprsSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring". 
gprsSSF postconditions: 

(1) No gprsSSF FSM state transition. 

On receipt of this operation, the gprsSSF performs actions to send the Advice of Charge information to the MS, 
provided that the SGSN supports Advice of Charge. 

If Advice of Charge is to be provided to an MS in conjunction with "CSE control of GPRS Session or PDP Context 
duration or volume", then the following sequence of operations shall be sent from the gsmSCF to the gprsSSF in the 
following order and in the same TC TC -CONTINUE or TC -BEGIN component: 

ApplyChargingGPRS ; SendCharginglnformationGPRS . 

These operations shall be processed sequentially by the gprsSSF, in the order that they are sent by the gsmSCF. In this, 
case parameter Tariffs witchlnterval may be present either in the ApplyChargingGPRS operation or in the 
SendCharginglnformationGPRS operation, but not in both operations. It is recommended that this parameter be 
transported in the ApplyGPRS Charging operation. 

The Tariffs witchlnterval information received with either one of these operations shall set the same tariff switch timer 
in the gprsSSF. This duration timer shall run from the time of successful operation execution. 

13.14.2.2 Error handling 

"TaskRefused": In addition to the generic error handling noted below, this error shall be indicated when: 

a tariffs witchlnterval is indicated when a previously received tariffs witchlnterval is pending. 

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for 
reporting operation errors are described in clause 14. 
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14 Services assumed from lower layers 
14.1 Services assumed from TC 

The SS7 application layer protocol defined in this 3GPP TS, is a protocol to provide communication between a pair of 
application processes. In the SS7 environment this is represented as communication between a pair of 
application-entities (AEs) using the TC. The function of an AE is provided by a set of application-service-elements 
(ASEs). The interaction between AEs is described in terms of their use of the services provided by the ASEs. 

If AC are to be used for FE differentiation within a physical node, then the version of TC used must support the 
dialogue portion of TC (i.e. ETSI ETS 300 287-1 [22]). 

This requirement applies to all interfaces, not just those used for internetworking. 

Table 14-1 defines which versions of TC are the minimum versions required to support the defined CAP interfaces: 

Table 14-1 : Minimum TC requirements for CAP interfaces 



Interface 


CAP 


gsmSSF - gsmSCF 


White Book 


gsmSRF - gsmSCF 


White Book 


assist gsmSSF - gsmSCF 


White Book 


smsSSF - gsmSCF 


White Book 


gprsSSF - gsmSCF 


White Book 



14.1.1 Common procedures 



The present subclause defines the procedures and mapping which apply between CAP and TC to be used in the absence 
of specific procedures and mapping instructions for the specific CAP interfaces as defined in subsequent subclauses. 



14.1.1.1 



Normal procedures 



The present subclause describes the procedures and TC primitives that shall be used for transmitting messages between 
AEs under normal operation. 

The CAP, as TC-user, uses only the structured dialogue facility provided by TC. The following situations can occur 
when a message is sent between two PE: 

a dialogue shall be established: the TC-user issues a TC -BEGIN request primitive. 

a dialogue shall be maintained: the TC-user issues a TC-CONTINUE request primitive. 

a dialogue shall no longer be maintained: the TC-user issues a TC-END request primitive with either basic end 
or with pre-arranged end depending on the following conditions: 

Basic End 

In the case the dialogue is established, operations, leading to a termination of the relationship, can be 
transmitted by the FE with a TC-END request primitive (basic) in the case the FE is not interested in the 
reception of any ERROR or REJECT components for these sent operations. Once the FE dialogue resources 
have been released, any ERROR or REJECT components received for these operations will be discarded by 
TC as described in ETSI ETS 300 287- 1 [22] . 

In the case that the dialogue is established and the FE has received an operation, leading to the termination of 
the relationship, does not wish to continue dialogue and there is no operation to be sent, a TC-END request 
primitive (basic) with zero components can be sent from the FE. 
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Pre-arranged End 

Where an entity is interested in possible ERROR or REJECT messages on response to sent operations 
leading to a termination of the relationship, the dialogue is ended with a TC-END request primitive 
(pre-arranged end) after the last associated operation timer expires. The receiving entity can end the dialogue 
with a TC-END request primitive (pre-arranged end) after successful processing of these operations (i.e. the 
relationship is terminated). 

in general, the use of prearranged end shall be limited to the case for both communicating entities clearly 
recognizable that peer entity applies prearranged end. In all other cases, basic end shall be used. 

14.1.1.2 Abnormal procedures 

The present subclause describes the procedures and TC primitives that shall be used for reporting abnormal situations 
between AEs. The error cases are defined in clause 10. 

The following primitives shall be used to report abnormal situations: 

operation errors, as defined in the CAP, are reported with TC-U-ERROR request primitive. 

rejection of a TC component by the TC-user shall be reported with TC-U-REJECT request primitive. 

when the FE detecting error or rejecting operation decides the termination of TC dialogue, TC-END request 
primitive (basic) with error or reject can be used for the termination of TC dialogue. 

when the gsmSSF or the gsmSRF detecting error or rejecting operation recognizes the possibility to continue 
dialogue, TC-CONTINUE request primitive with error or reject can be used for the continuation of TC dialogue. 

a dialogue shall be aborted by the TC-user with a TC-U-ABORT request primitive. 

on expiration of application timer Tssf or Tsrf, dialogue shall be terminated by means of by TC-U-ABORT 
primitive with an Abort reason, regardless of TC dialogue is established or not. 

For abnormal situations detected by TC the same rules shall apply for reception of TC-R-REJECT indication as for 
transmission of TC-U-REJECT request and for transmission of TC-P-ABORT indication as for transmission of 
TC-U-ABORT request primitive. 

The following rules shall be applied to terminate the TC dialogue under abnormal situations: 

in the case that abort condition is detected and TC dialogue is established, TC dialogue is terminated by 
TC-U-ABORT primitive with an Abort reason. 

in the case that abort condition is detected and TC dialogue is not established, TC dialogue is locally terminated 
by TC-U-ABORT primitive, (in the case such as application time out). 

In error situations prearranged end shall not be used to terminate the TC dialogue. In the case any AE encounters an 
error situation the peer entity shall be explicitly notified of the error, if possible. If from any entity"s point of view the 
error encountered requires the relationship to be ended, then it shall close the dialogue via a TC-END request primitive 
with basic end or via a TC-U-ABORT request primitive, depending on whether any pending ERROR or REJECT 
component is to be sent or not. 

In the case an entity receives a TC-END indication primitive and after all components have been considered, the FSM is 
not in a state to terminate the relationship, an appropriate internal error should be provided. 

In cases when a dialogue needs to be closed by the initiating entity before its establishment has been completed (before 
the first TC indication primitive to the TC-BEGIN request primitive has been received from the responding entity), the 
TC-user shall issue a TC-END request primitive with prearranged end or a TC-U-ABORT request primitive. The result 
of these primitives will be only local, any subsequent TC indication received for this dialogue will be handled in 
accordance with the abnormal procedures as specified in ETSI ETS 300 287-1 [22]). 

When the gsmSSF, gprsSSF or smsSSF receives multiple Operation components in a single TC Message and there is an 
error in the processing of one of these Operations, then the gsmSSF FSM, gprsSSF FSM or smsSSF FSM shall process 
the error and shall discard all Operation components in that TC Message of which the processing has not yet started. 
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1 4.1 .1 .3 Dialogue handling 
14.1.1.3.1 Dialogue establishment 

The establishment of a CAP dialogue involves two application processes as described in clause 1, one that is the 
dialogue-initiator and one that is the dialogue-responder. 

This procedure is driven by the following signals: 

A TC-BEGIN request primitive from the dialogue-initiator. 

A TC-BEGIN indication primitive occurring at the responding side 

The first TC -CONTINUE indication primitive occurring at the initiating side or under specific conditions: 

A TC-END indication primitive occurring at the initiating side 

A TC-U- ABORT indication primitive occurring at the initiating side 

A TC-P- ABORT indication primitive occurring at the initiating side 

Sending of a TC-BEGIN request 

Before issuing a TC-BEGIN request primitive, TC-USER shall store the AC-name and if present the user-information 
parameter. 

TC-USER shall request the invocation of the associated operations using the TC-INVOKE service. See 
subclause 14.1.1.4.1 for a description of the invocation procedure. 

After processing of the last invocation request, TC-USER shall issue a TC-BEGIN request primitive. 

The initiator TC-USER then waits for a TC indication primitive and will not issue any other requests, except a 
TC-U- ABORT request or a TC-END request with the release method parameter set to "pre-arranged release". 

Receipt of a TC-BEGIN indication 

On receipt of a TC-BEGIN indication primitive, responder TC-USER shall: 

Analyse the application-context-name included in the primitive. If it is supported, then process any other 
indication primitives received from TC as described in subclause 14.1.1.4.1. 

If the application-context-name included in the primitive is not supported, then issue a TC-U- ABORT request 
primitive. 

Receipt of the first TC-CONTINUE indication 

On receipt of the first TC-CONTINUE indication primitive for a dialogue, TC-USER shall check the value of the 
application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive, then 
TC-USER shall process the following TC component handling indication primitives as described in 
subclause 14.1.1.4.1, otherwise it shall issue a TC-U- ABORT request primitive. 

Receipt of a TC-END indication 

On receipt of a TC-END indication primitive in the dialogue initiated state, TC-USER shall check the value of the 
application-context-name parameter. If this value match the one used in the TC-BEGIN request primitive, then the 
TC-USER shall process the following TC component handling indication primitives as described in 
subclause 14.1.1.4.1. 

Receipt of a TC-U-ABORT indication 

Receipt of a TC-U-ABORT indication primitive is described as part of user abort procedure (see 14.1.1.3.4.). 

Receipt of a TC-P-ABORT indication 

Receipt of a TC-P-ABORT indication primitive is described as part of provider abort procedure (see 14.1.1.3.5.). 
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14.1.1.3.2 Dialogue continuation 

Once established the dialogue is said to be in a continuation phase. 

Both application processes can request the transfer of CAP APDUs until one of them requests the termination of the 
dialogue. 

Sending entity 

TC-USER shall process any component handling request primitives as described in subclause 14.1.1.4.1. 

After processing the last component handling request primitive, TC-USER shall issue a TC -CONTINUE request 
primitive. 

Receiving entity 

On receipt of a TC -CONTINUE indication primitive TC-USER shall accept zero, one or several TC component 
handling indication primitives and process them as described in subclause 14.1.1.4.1. 

14.1.1.3.3 Dialogue termination 

Both the dialogue-initiator and the dialogue-responder have the ability to request the termination of a dialogue after it 
has been established when no dialogue is to be established or when a dialogue is no longer to be maintained according 
to the rules as stated in subclauses 14.1.2.1.1 and 14.1.2.1.2. 

The dialogue termination procedure is driven by the following events: 

A TC-END request primitive 

A TC-END indication primitive 

Sending of TC-END request 

When the dialogue shall no longer be maintained, TC-USER shall process any component handling request primitives 
as described in subclause 14.1.1.4.1 

After processing the last component handling request primitive (if any), TC-USER shall issue a TC-END request 
primitive with the release method parameter set to "basic end" or "prearranged release", in accordance with the rules as 
stated in subclauses 14.1.2.1.1 and 14.1.2.1.2. 

When no dialogue is to be established, refer to subclauses 14.1.1.3.1. 

Receipt of a TC-END indication 

On receipt of a TC-END indication primitive, the TC-USER shall accept any component handling indication primitives 
and process them as described in subclause 14.1.1.4.1. 

After processing the last component handling primitive all dialogue related resources are released. 

14.1.1.3.4 User abort 

Both the dialogue-initiator and the dialogue-responder have the ability to abort a dialogue at any time. 
The user abort procedure is driven by one of the following events: 

- A TC-U-ABORT request primitive 

- A TC-U-ABORT indication primitive 
Sending of TC-U-ABORT request 

After issuing a TC-U-ABORT request primitive, all dialogue related resources are released. 

Receipt of a TC-U-ABORT indication 

On receipt of a TC-U-ABORT indication all dialogue related resources are released. 
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14.1.1.3.5 Provider abort 

TC has the ability to abort a dialogue at both the dialogue-initiator side and the dialogue-responder side. 
The provider abort procedure is driven by the following event: 

- A TC-P- ABORT indication primitive 
Receipt of a TC-P-ABORT indication 
On receipt of a TC-P-ABORT indication, all dialogue related resources are released. 

14.1.1.3.6 Mapping toTC dialogue primitives 

The TC-UNI service is not used by CAP. 

The mapping of parameters onto the TC Dialogue services is as follows: 

The use of parameters of the TC-BEGIN service is as defined in subclause 14.1.1.3.7 with the following qualifications: 

The Destination Address parameter of the TC-BEGIN service shall be set to the CAP address of the AE which is 
to respond to the TC-BEGIN service. 

NOTE 1 : The address used in this parameter may be mapped by SCCP address translation to one of a number of 
alternative AEs. 

The AC Name parameter of the TC-BEGIN service shall be set according to the specific interface being used 
between the initiating AE and the responding AE. 

The Originating Address parameter of the TC-BEGIN service shall be set to the unambiguous CAP address of 
the AE initiating the TC-BEGIN service. 

The use of parameters of the TC-CONTINUE service is as defined in subclause 14.1.1.3.7 with the following 
qualifications: 

The AC Name parameter of the TC-CONTINUE service shall be set to the value of the AC Name parameter of 
the TC-BEGIN service for the same TC Dialogue ID parameter value. 

If present, the Originating Address parameter of the TC-CONTINUE service shall be set to the unambiguous 
CAP address of the AE initiating the TC-CONTINUE service. This parameter is present only in the first 
TC-CONTINUE service after a TC-BEGIN service with the same TC Dialogue ID parameter value. 

The use of parameters of the TC-END service is as defined in subclause 14.1.1.3.7 with the following qualifications: 

The AC Name parameter of the TC-END service shall be set to the value of the AC Name parameter of the 
TC-BEGIN service for the same TC Dialogue ID parameter value. This parameter is present only if the TC-END 
service is used immediately after the TC-BEGIN service. 

The use of parameters of the TC-U-ABORT service is as defined in subclause 14.1.1.3.7 with the following 
qualifications: 

The Abort Reason parameter of the TC-U-ABORT service shall be used as specified in ETSI ETS 300 287- 
1 [22]. 

The AC Name parameter of the TC-U-ABORT service shall be set to the value used in the TC-BEGIN service. 

NOTE 2: This parameter is present only if the TC-U-ABORT is the immediate response to a TC-BEGIN 
indication. 

The use of parameters of the TC-P-ABORT service is as defined in subclause 14.1.1.3.7 with the following 
qualifications: 

The P-Abort parameter of the TC-P-ABORT service is set by TC to indicate the reason why TC aborted the 
dialogue. It shall take the values as defined in ETSI ETS 300 287-1 [22]. 
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14.1.1.3.7 Default mapping toTC dialogue parameters 

Dialogue Id 

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. This 
parameter uniquely identifies a specific TC dialogue to a remote CAP AE for a CAP AE. 

Application-context-name 

The application-context-name parameter is set in accordance with the set of Operations which need to be supported by 
the TC dialogue. The defined AC Names can be found in clauses 6 to 8. 

User information 

This parameter may be used by both initiating and responding application processes. This parameter shall be used for 
the CAP-GPRS-ReferenceNumber as defined in 14.1.7. For interfaces other than the gprsSSF-gsmSCF interface and for 
SMS related messages (as in subclauses 14.1.3, 14.1.4 and 14.1.5) the receiving side may ignore this parameter if 
received. The User Information parameter shall be encoded in accordance with the definition provided in ITU-T 
Recommendation Q.773 [46], subclause 3.2, and the definition of EXTERNAL type provided in ITU-T 
Recommendation X.690 [57], with the restriction that: 

- a size ( 1 . . 1 0) constraint of SEQUENCE OF EXTERNAL; 

an Object Identifier shall always be present to identify the user information and the entity which sent it; 

a single-ASN-1-type is used for encoding. 

For the use of CAP defined TC-U- Abort reason, see the ASN.l notation in the subclause 5.7. 

For the use of CAP defined CAP-GPRS-ReferenceNumber, see subclause 14.1.7. For the abstract syntax of CAP 
defined CAP-GPRS-ReferenceNumber, see the ASN.l notation in the subclause 8.1. 

Component present 

This parameter is used by TC-USER as described in ETSI ETS 300 287-1 [22]. 

Termination 

The value of the release method parameter of the TC-END request primitive is set by TC-USER according to the rules 
as stated in subclauses 14.1.2.1.1 and 14.1.2.1.2. 

Quality of service 

The quality of service of TC request primitives is set by the TC-USER to the following value: 

- Sequencing requested; 

- return option, this parameter is set by TC-USER in an implementation dependent manner. 

14.1.1.4 Component handling 

14.1.1.4.1 Procedures for CAP Operations 

The present subclause describes the procedures for CAP Operations. 

Operation invocation 

TC-USER shall build an operation argument from the parameters received and request the invocation of the associated 
operation using the TC-INVOKE procedure. If a linked ID parameter is inserted in the primitive, then this indicates a 
child operation and implies that the operation is linked to a parent operation. 
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Operation invocation receipt 

On receipt of a TC -INVOKE indication primitive, TC-USER shall: 

If the operation code does not correspond to an operation supported by the application-context, then request the 
transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code 
(unrecognized operation); 

If a linked ID is included, then perform the following checks: If the operation referred to by the linked ID does 
not allow linked operations or if the operation code does not correspond to a permitted linked operation, or if the 
parent operation invocation is not active, then request the transfer of a reject component using the 
TC-U-REJECT request primitive, with the appropriate problem code (linked response unexpected or unexpected 
linked operation); 

If a linked ID is not included, but a Linked ID is needed to correlate the indication primitive with a parent 
operation invocation, then request the transfer of a reject component using the TC-U-REJECT request 
primitive, with the appropriate problem code (mistyped parameter); 

If the type of the argument is not the one defined for the operation, then request the transfer of a reject 
component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter); 

If the operation cannot be invoked because the CAP related dialogue is about to be released, then request the 
transfer of a reject component using the TC-U-REJECT request primitive with the problem code (Initiating 
Release); 

If sufficient CAP related resources are not available to perform the requested operation, then request the transfer 
of a reject component using the TC-U-REJECT request primitive with the problem code (Resource Limitation); 

Otherwise, accept the TC-INVOKE indication primitive. If the operation is to be user confirmed, then TC-USER 
waits for the corresponding response. 

Operation Response 

For user confirmed operations, TC-USER shall: 

If no error indication is included in the response to a class 1 or 3 operation, then construct a result information 
element from the parameters received and request its transfer using the TC-RESULT-L service. 

If an error indication is included in the response to a class 1 or 2 operation, then construct an error parameter 
from the parameters received and request its transfer using the TC-U-ERROR request primitive. 

Receipt of a response 

On receipt of a TC-RESULT-NL indication, TC-USER shall: 

Request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate 
problem code (mistyped parameter). 

On receipt of a TC-RESULT-L indication, TC-USER shall: 

If the type of the result parameter is not the one defined for the result of this operation, request the transfer of a 
reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped 
parameter); 

Otherwise, accept the TC-RESULT-L indication primitive. 

On receipt of a TC-U-ERROR indication, TC-USER shall: 

If the error code is not defined for the TC-USER or is not one associated with the operation referred to by the 
invoke ID, request the transfer of a reject component using the TC-U-REJECT request primitive, with the 
appropriate problem code (unrecognized error or unexpected error); 

If the type of the error parameter is not the one defined for this error, request the transfer of a reject component 
using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter); 

Otherwise, accept the TC-U-ERROR indication primitive. 
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On receipt of a TC-U-REJECT indication primitive which affects a pending operation, TC-USER shall: 

accept the TC-U-REJECT indication primitive. 

On receipt of a TC-L-REJECT indicating "return result problem, return error unexpected", TC-USER shall inform the 
application process. 

On receipt of a TC-L-REJECT indicating "return error problem, return error unexpected", TC-USER shall inform the 
application process. 

This event occurs when the local TC detects a protocol error in an incoming component which affects an operation. 

When the problem code indicates a general problem, it is considered that the event cannot be related to an active 
operation even if the invoke Id is provided by TC. This is because it is unclear whether the invoke Id refers to a local or 
remote invocation. The behaviour of TC-USER in such a case is described in the subclause headed "other events". 

On receipt of a TC-L-CANCEL indication, the TC-USER shall: 

If the associated operation is a class 1 operation, inform the application process; 

If the associated operation is a class 2 operation and no linked operations are defined for this operation, ignore 
the primitive; 

If the associated operation is a class 2 operation and has linked operations but none of them has been invoked, 
inform the application process; 

If the associated operation is a class 2 operation and a linked operation invocation has already been received in 
response to this operation, ignore the primitive; 

If the associated operation is a class 3 operation, inform the application process; 

If the associated operation is a class 4 operation, ignore the primitive; 

Other events 

This subclause describes the behaviour of TC-USER on receipt of a component handling indication primitive which 
cannot be related to any operation or which does not affect a pending one. 

On receipt of a TC-U-REJECT indication primitive which does not affect an active operation (i.e. indicating a return 
result or return error problem), it is up to the application process to abort, continue or terminate the dialogue, if not 
already terminated by the sending application process according to the rules as stated in subclause 14.1.2.1.2. This is 
also applicable for invoke problems related to a class 4 linked operation. 

On receipt of a TC-R-REJECT indication (i.e. when a protocol error has been detected by the peer TC entity) which 
does not affect an active operation, it is up to the application process to abort, continue or terminate the dialogue, if not 
already terminated by the sending application process according to the rules as stated in subclause 14.1.2.1.2. 

On receipt of a TC-L-REJECT indication primitive (i.e. when a protocol error has been detected by the local TC entity) 
which cannot be related to an active operation, it is up to the application process to continue, or to terminate the 
dialogue and implicitly trigger the transmission of the reject component or to abort the dialogue. 

On receipt of a TC -NOTICE indication primitive, which informs the TC-USER that a message cannot be delivered by 
the Network Layer, it is for the application process to decide whether to terminate the dialogue or retry. 

This primitive can occur only if the Return Option has been set (see subclause 14.1.1.3.6). 

14.1.1.4.2 Mapping toTC component primitives 

The mapping of parameters onto the TC Component services is as follows: 

The TC-U-CANCEL service is not used. 

The TC-RESULT-NL service is not used. 

The use of parameters of the TC-INVOKE service is as defined in subclause 14.1.1.4.3 with the following 
qualifications: 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 194 ETSI TS 129 078 V8.2.1 (2010-04) 

The Operation parameter of the TC-IN VOKE service shall contain the operation. &operationCode value of the 
CAP Operation to be invoked. The operation must be one of the valid operations supported by the AC for the TC 
dialogue and must be invokable by the local AE. 

The Parameters parameter of the TC-IN VOKE service shall contain a value of the operation. &ArgumentType 
value for the operation being invoked, as specified by the Operation parameter. 

The use of parameters of the TC-RESULT-L service is as defined in subclause 14.1.1.4.3 with the following 
qualifications: 

The Invoke Id parameter of the TC-RESULT-L service shall be set to the value of the Invoke Id parameter of the 
TC-INVOKE service from the remote AE to which a result is being sent. 

The Operation parameter of the TC-RESULT-L service be set to the value of the Operation parameter of the 
TC-INVOKE service from the remote AE which contains the same Invoke Id Parameter value. 

The Parameters parameter of the TC-RESULT-L service shall contain the operation. &ResultType value for the 
operation result, as specified by the Operation parameter. 

The use of parameters of the TC-U-ERROR service is as defined in subclause 14.1.1.4.3 with the following 
qualifications: 

The Invoke Id parameter of the TC-U-ERROR service shall be set to the value of the Invoke Id parameter of the 
TC-INVOKE service from the remote AE to which an error is being sent. 

The Error parameter of the TC-U-ERROR service shall be set to the value of the error. &errorCode of the error 
to be sent. It must be one of the errors which is expected for the invoked operation as defined in the 
operation. &Errors specification. 

The Parameters parameter of the TC-U-ERROR service shall be set to the value of the error. &ParameterType of 
the error to be sent, as identified by the Error parameter. 

The use of parameters of the TC-U-REJECT service is as defined in subclause 14.1.1.4.3 with the following 
qualifications: 

The Invoke Id parameter of the TC-U-REJECT service shall be set to the Invoke Id Parameter of the TC 
component service from the remote AE which is being rejected. 

The use of parameters of the TC-L-CANCEL service is as defined in subclause 14.1.1.4.3. 

14.1.1.4.3 Default mapping to TC component parameters 

Invoke Id 

This parameter is set by the sending application process. It represents the unique identity of an instance of an operation 
which is invoked by an AE within a specific TC dialogue. The TC dialogue is identified by the Dialogue Id parameter. 

Linked Id 

This parameter is set by the sending application process. It represents the Invoke Id of an operation which was received 
from the remote AE for a specific TC dialogue to which the operation being invoked by the local AE is to be linked. 
This parameter is present only if the original operation invoked by the remote AE is defined as having linked 
operations. The type of local operation invoked must be the same type as one of the operations defined as being linked. 

Dialogue Id 

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. It 
represents the identity of the established TC dialogue which will carry the component services between the local AE 
and the remote AE. 

Class 

The value of this parameter is set according to the type of the operation to be invoked according to the operation 
definitions in clauses 6 through 8. 
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Time out 

The value of this parameter is set according to the type of operation invoked. 

Last component 

This parameter is used as described in ETSI ETS 300 287-1 [22]. 

Problem code 

This parameter is used as described in subclause 14.1.1.4.1. 

Abort reason 

This parameter is used by TC-USER, and attributes and coding are specified by network operator. 

14.1.2 gsmSSF-gsmSCF interfaces 

14.1.2.1 Normal procedures 

14.1.2.1.1 gsmSSF-to-gsmSCF messages 

The present subclause defines the normal procedures for TC messages from the gsmSSF to the gsmSCF. 

gsmSSF FSM related messages 

A dialogue shall be established when the gsmSSF FSM transits from the state "Idle" to the state 
" Waiting_for_Instructions " . 

The CAP Operation InitialDP shall be sent with a TC -BEGIN request primitive. 

When the dialogue was opened with InitialDP or InitiateCallAttempt operation then the gsmSSF shall maintain the 

dialogue when sending the SpecializedResourceReport operation indicating the announcement complete for 

Play Announcement regardless of the fact whether the disconnectFromlPForbidden parameter was set to true or false. 

For all other operations sent from the gsmSSF FSM, the dialogue shall be maintained except for the following cases. 

When the gsmSSF FSM executes a non-error case state transition to the state "Idle" and there is one or more pending 
operation and TC dialogue is established, TC dialogue can be terminated by TC-END primitive with component(s). 
When the gsmSSF sends the last EventReportBCSM, ApplyChargingReport or CalllnformationReport the dialogue may 
be ended from the gsmSSF by a TC-END request primitive with basic end. 

In the case that there is no pending operation and TC dialogue is established, TC dialogue can be terminated by 
TC-END primitive with zero component or prearranged end. When the gsmSSF FSM makes a non-error case state 
transition to the state "Idle" and there is no operation to be sent, the dialogue is ended by means of a TC-END request 
primitive (basic) with zero components, or the dialogue is locally ended by means of a TC-END request primitive with 
prearranged end. 

In the case where a call release is initiated by any other entity than a gsmSCF, the gsmSSF can end a dialogue with a 
TC-END request primitive with zero component or prearranged end if a TC dialogue is established and the gsmSSF has 
no pending call information requests (or pending requests which should be treated in the same way, see 
subclause 14.1.1.1) nor any armed EDP. 

When the gsmSSF has sent the last EventReportBCSM, ApplyChargingReport or CalllnformationReport the dialogue 
may be ended from the gsmSCF by a TC-END request primitive with basic end. 

Assisting gsmSSF FSM related messages 

A dialogue shall be established when the assisting gsmSSF FSM transits from the state "Idle" to the state 
"Waiting_for_Instructions". The AssistRequestlnstructions operation shall be transmitted with a TC-BEGIN request 
primitive. 

For all other operations sent from the assisting gsmSSF FSM, the dialogue shall be maintained except for the following 

cases. 
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When the assisting gsmSSF FSM makes a non-error case state transition to the state "Idle" and there is one or more 
pending operation and TC dialogue is established, TC dialogue can be terminated by TC-END primitive with 
component(s). 

In the assisting gsmSSF case the same rules apply as for the gsmSRF as specified for the SpecializedResourceReport 
operation in subclause 14.1.3.1.1. 

In the case that there is no pending operation and TC dialogue is established, TC dialogue can be terminated by 
TC-END primitive with zero component or prearranged end. When the assisting gsmSSF FSM makes a non-error case 
state transition to the state "Idle" and there is no operation to be sent, the dialogue is ended by means of a TC-END 
request primitive (basic) with zero components, or the dialogue is locally ended by means of a TC-END request 
primitive with prearranged end. 

gsmSSME FSM related messages 

The following procedures shall be followed: 

The dialogue shall be maintained when the ActivityTest Return Result is sent. 

14.1.2.1.2 gsmSCF-to-gsmSSF messages 

The present subclause defines the normal procedures for TC messages from the gsmSCF to the gsmSSF. 

SCSM-FSM related messages 

A dialogue shall be established when the SCSM-FSM receives an InitialDP operation for TDP-R or an 
AssistRequestlnstructions operation, or sends an InitiateCallAttempt operation. 

For subsequent operations sent from the SCSM-FSM, the dialogue shall be maintained except for the following cases; 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the 
gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and 
when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request primitive 
with prearranged end. 

Alternatively, the sending of operations, leading to the termination of the relationship, by means of a TC-END request 
primitive (basic end) is possible. 

SCME-FSM related messages 

The operations sent from the SCME-FSM shall be issued according to the following procedures: 

The dialogue shall be maintained when the ActivityTest operation is sent. 

For sending one or more CallGap operations, the SCME FSM shall use an existing SCSM FSM associated 
dialogue which was initiated by a gsmSSF FSM (i.e. established for the transmission of the InitialDP operation). 
The dialogue shall be maintained. 

14.1.2.1.3 smsSSF -to-gsmSCF SMS related messages 

A dialogue shall be established when the smsSSF has finalised trigger processing and transits to the state 
"Waiting_for_Instructions". The relevant CAP Operation, which can be the InitialDPSMS operation only, shall be 
transmitted in the same message. 

For all other operations sent from the smsSSF, the dialogue shall be maintained. 

The dialogue shall no longer be maintained when the prearranged end condition is met in the smsSSF. When the 
smsSSF makes a state transition to the state "Idle", the dialogue is locally ended by means of a TC-END request 
primitive with prearranged end. 

When the smsSSF FSM transits to the state "Idle", but no event was reported to the gsmSCF, then the smsSSF shall 
send TC-END with zero components to the gsmSCF. 

When the smsSSF has sent the last EventReportSMS operation the dialogue may be ended from the gsmSCF by a 
TC-END request primitive with basic end. If the smsSSF decides to apply basic end, then it shall send TC-END with 
zero components. 
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14.1.2.1.4 gsmSCF-to-smsSSF SMS related messages 

All operations are sent after a dialogue was established from the smsSSF (the gsmSCF has previously received a 
TC -BEGIN indication primitive with an InitialSMSEvent operation). 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the 
gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and 
when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request primitive 
with prearranged end. 

Alternatively, the sending of operations, leading to the termination of the control relationship, by means of a TC-END 
request primitive (basic end) is possible. 

14.1.2.1.5 Use of dialogue handling services 

Dialogue handling services are used to trigger the sending of the APDUs associated with the operations involved in the 
CAP packages. 

Component grouping is performed under the control of the application-process through an appropriate usage of the 
TC-BEGIN, TC-CONTINUE and TC-END service. 

14.1.2.2 Abnormal procedures 

The following procedures also apply to the gsmSCF-gsmSRF interfaces. 

14.1.2.2.1 gsmSCF-to-gsmSSF/gsmSRF messages 

Considering that gsmSSF and gsmSRF do not have the logic to recover from error cases detected on the 
gsmSCF-gsmSSF/gsmSRF interface, the following shall apply: 

Operation errors and rejection of TC components shall be transmitted to the gsmSSF and, respectively, the 
gsmSRF with a TC-END request primitive, basic end. 

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC-CONTINUE 
indication primitive, then the gsmSSF and, respectively, the gsmSRF shall abort the dialogue with a TC-U-ABORT 
request primitive. 

14.1.2.2.2 gsmSSF/gsmSRF/ -to-gsmSCF messages 

Operation errors and rejection of TC components shall be transmitted to the gsmSCF according to the following rules: 

The dialogue shall be maintained when the preceding message, which contained the erroneous component, 

indicated that the dialogue shall be maintained. I.e. the error or reject shall be transmitted with a 

TC-CONTINUE request primitive if the erroneous component was received with a TC-CONTINUE indication 

primitive. 

On receipt of an ERROR or REJECT component the gsmSCF decides on further processing. It may either 

continue, explicitly end or abort the dialogue. 

When the gsmSSF has received and processed InitiateCallAttempt and has acknowledged InitiateCallAttempt 
with InitiateCallAttempt-RESULT, then a User Error resulting from an erroneous component that is contained in 
the same TC_Begin message as InitiateCallAttempt, shall be transmitted with a TC-CONTINUE indication 
primitive. 

In all other situations the dialogue shall no longer be maintained. I.e. the error or reject shall be transmitted with 
a TC-END request primitive, basic end, if the erroneous component was received with a TC-BEGIN indication 
primitive. 

on expiration of application timer Tssf or Tsrf, dialogue shall be terminated by means of by TC-U-ABORT 
primitive with an Abort reason, regardless of TC dialogue is established or not. 

If the error processing in the gsmSSF or gsmSRF leads to the case where the gsmSSF or gsmSRF is not able to process 
further gsmSCF operations while the dialogue is to be maintained, then the gsmSSF or gsmSRF aborts the dialogue 
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with a TC-END request primitive with basic end or a TC-U-ABORT request primitive, depending on whether any 
pending ERROR or REJECT component is to be sent or not. 

The gsmSSF can end a dialogue with a TC-U-ABORT request primitive in the case that call release is initiated by any 
other entity then the gsmSCF and the gsmSSF has no pending call information requests (or pending requests which 
should be treated in the same way, i.e., ApplyCharging nor any armed EDP to notify the gsmSCF of the call release (for 
alternative way, see subclause 14.1.2.1.1). 

1 4. 1 .2.2.3 gsmSCF-to-smsSSF SMS related messages 

Considering that the smsSSF does not have the logic to recover from error cases detected on the gsmSCF-smsSSF 
interface, the following shall apply: 

operation errors and rejection of TC components shall be transmitted to the smsSSF with a TC-END request 
primitive, basic end. 

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC -CONTINUE 
indication primitive, then the smsSSF shall abort the dialogue with a TC-U-ABORT request primitive. 

14.1.2.2.4 smsSSF-to-gsmSCF SMS related messages 

Operation errors and rejection of TC components shall be transmitted to the gsmSCF according to the following rules: 

the dialogue shall be maintained when the preceding message, which contained the erroneous component, 
indicated that the dialogue shall be maintained. I.e. the error or reject shall be transmitted with a 
TC-CONTINUE request primitive if the erroneous component was received with a TC-CONTINUE indication 
primitive; 

on receipt of an ERROR or REJECT component the gsmSCF decides on further processing. It may either 
continue, explicitly end or abort the dialogue; 

If the error processing in the smsSSF leads to the case where the smsSSF is not able to process further gsmSCF 
operations while the dialogue is to be maintained, then the smsSSF aborts the dialogue with a TC-U-ABORT request 
primitive. 

The smsSSF aborts a dialogue with a TC-U-ABORT request primitive if release is initiated by any other entity than the 
gsmSCF and the smsSSF has no armed EDPs to notify the gsmSCF. 

14.1 .2.2.5 Use of dialogue handling services 

On receipt of a TC-U-REJECT.ind in the FE, this primitive should be ignored. It is up to the application process to 
abort, continue or terminate the dialogue, if not already terminated by the sending application process according to the 
rules as stated in subclause 14.1.1.2. This is also applicable for invoke problems related to a class 4 linked operation. 

A TC-U-REJECT.req should be sent followed by a TC-CONTINUE.req. 

On receipt of a TC-R-REJECT.ind in the FE, this primitive should be ignored. It is up to the application process to 
abort, continue or terminate the dialogue, if not already terminated by the sending application process according to the 
rules as stated in subclause 14.1.1.2. This is also applicable for invoke problems related to a class 4 linked operation. 

On receipt of a TC-L-REJECT indication primitive (i.e. when a protocol error has been detected by the local TC entity) 
which cannot be related to an active operation, it is up to the application process to continue or to terminate the dialogue 
and implicitly trigger the transmission of the reject component or to abort the dialogue. 

On receipt of a TC -NOTICE indication the TC-USER is informed that a message cannot be delivered by the Network 
Layer. It occurs if the Return Option has been set (see subclause 14.1.1.3.7). It is for the application process to decide 
whether to terminate the dialogue or retry. 

The application-process is the sole user of the TC-P-ABORT service and TC-NOTICE service. 

The receipt of a TC-U-ABORT-Ind or TC-P-ABORT-Ind on a dialogue terminates all request processing. 
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1 4.1 .2.3 Dialogue handling 

14.1.2.3.1 Dialogue establishment 

14.1.2.3.2 Dialogue continuation 

14.1.2.3.3 Dialogue termination 

14.1.2.3.4 User abort 

14.1.2.3.5 Provider abort 

14.1 .2.3.6 Mapping to TC dialogue primitives 

The gsmSSF-gsmSCF IN services can be mapped onto TC services. The present subclause defines the mapping of the 
gsmSSF-gsmSCF IN services onto the services of the TC dialogue handling services defined in ETSI ETS 300 287- 
1[22]. 

a) The TC-BEGIN service is used to invoke the operations of the gsmSCF-gsmSSF connection packages as defined 
in clause 6. 

b) The TC-CONTINUE service is used to report the success of the operations invoked in a TC-BEGIN service and 
to invoke or respond to any other operations. 

c) The TC-U- ABORT service is used to report the failure of operations of the connection packages as defined in 
clause 6. 

The mapping of the parameters onto the TC-BEGIN primitive is defined in subclause 14.1.1.3.6 with the following 
qualifications: 

The AC Name parameter shall take the value of the application-context-name field of the cap3-sms-AC object if 
the initiating AE is a gsmSSF. 

The mapping of the parameters onto the TC-CONTINUE primitive is defined in subclause 14.1.1.3.6. 

The mapping of the parameters onto the TC-U- ABORT primitive is defined in subclause 14.1.1.3.6 with the following 
qualifications: 

The Application-Context-Name parameter shall be used as specified in ETSI ETS 300 287-1 [22]. When the 
responding AE refuses a dialogue because the application-context-name it receives is not supported, this parameter 
shall have the value of the application-context-name field of the cap3-sms-AC object if the responding AE is a 
gsmSCF. 

The use of the parameters of the TC-END service is defined in subclause 14.1.1.3.6. 

1 4.1 .2.4 Component Handling 

14.1 .2.4.1 Procedures for CAP Operations 

The CAP ASEs are users of the TC component handling services except for the TC-L-REJECT and TC-L-CANCEL 
services which are used by the application-process. Receipt of a TC-L-REJECT-Ind leads the application-process to 
abandon the dialogue (i.e. it issues a TC-U-ABORT-Request primitive). 

The TC-U-CANCEL service is never used. 

1 4. 1 .2.4.2 Mapping to TC component parameters 

The gsmSSF-gsmSCF IN ASE services are mapped onto the TC component handling services. The mapping of 
operations and errors onto TC services is defined in subclause 14.1.1.4.2 with the following qualifications: 

The timeout parameter of the TC-INVOKE-Req primitives is set according to clause 6. 
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14.1.3 gsmSCF-gsmSRF interface 
14.1.3.1 Normal procedures 

14.1.3.1.1 gsmSCF-to/f rom-gsmSRF messages 

A dialogue is established when the gsmSRF sends an AssistRequestlnstructions operation to the gsmSCF. For all other 
operations sent to/from the gsmSRF, the dialogue shall be maintained. 

In the case that there is no pending operation and TC dialogue is established, TC dialogue can be terminated by 
TC-END primitive with zero component. When the SCSM makes a non-error case state transition to end-user 
interaction and there is no operation to be sent, the dialogue is ended by means of a TC-END request primitive (basic) 
with zero components. 

When the dialogue is opened with the AssistRequestlnstructions operation then the gsmSRF shall no longer maintain 
the dialogue when sending the SpecializedResourceReport operation indicating announcement complete for 
Play Announcement with disconnectFromlPForbidden parameter was set to false or Return Result of the 
PromptAndCollectUserlnformation with disconnectFromlPForbidden parameter was set to false. The dialogue is ended 
by means of a TC-END request primitive with basic end, and the SpecializedResourceReport operation is transmitted 
with the same request. 

Regardless of whether pending operation exists or not, when the SRSM-FSM is informed of the disconnection of bearer 
connection (in the case of gsmSCF initiated disconnection or call abandon from call party) and dialogue is established, 
the dialogue is ended by means of a TC-END request primitive (basic) with zero components or TC-END request 
primitive (prearranged end). 

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSRF. When the 
SRSM-FSM is informed the disconnection of bearer connection and TC dialogue is not established, TC dialogue is 
locally terminated by TC-END primitive with prearranged end. 

When the gsmSCF does not expect any messages other than possibly REJECT or ERROR messages for the operations 
sent and when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request 
primitive with prearranged end. Alternatively, the sending of operations, leading to the termination of the relationship, 
by means of a TC-END request primitive (basic end) is possible. 

In the relay case, the gsmSRF-gsmSCF relationship uses the gsmSSF-gsmSCF TC dialogue. This is possible, because 
begin and end of the gsmSRF-gsmSCF relationship are embedded in the gsmSSF-gsmSCF relationship. 
gsmSRF-gsmSCF information shall be exchanged with TC-CONTINUE request primitives. 

14.1.3.1.2 Abnormal procedures 

14.1.3.1.3 Dialogue handling 

14.1.3.1.3.1 Dialogue establishment 

14.1 .3.1 .3.2 Dialogue continuation 

14.1.3.1.3.3 Dialogue termination 

14.1.3.1.3.4 User abort 

14.1.3.1.3.5 Provider abort 

14.1 .3.1 .3.6 Mapping to TC dialogue primitives 

The gsmSCF-gsmSRF IN services can be mapped onto TC services. The present subclause defines the mapping of the 
gsmSCF-gsmSRF IN services onto the services of the TC dialogue handling services defined in ETSI ETS 300 287- 
1[22]. 
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a) The TC-BEGIN service is used to invoke the operations of the gsmSRF-gsmSCF connection packages as defined 
in clause 6. 

b) The TC-CONTINUE service is used to report the success of the operations invoked in a TC-BEGIN service and 
to invoke or respond to any other operations. 

c) The TC-U- ABORT service is used to report the failure of operation of the gsmSCF-gsmSRF operations 
packages as defined in clause 6. 

The mapping of parameters onto the TC Dialogue services is as defined in subclause 14.1.1.3.6 with the following 
qualifications: 

The mapping of the parameters onto the TC-BEGIN primitive is defined in subclause 14.1.1.3.6 with the following 
qualifications: 

The AC Name parameter shall take the value of the application-context-name field of the gsmSRF-gsmSCF-ac 
object. 

14.1.3.2 Component handling 

14.1 .3.2.1 Procedures for CAP Operations 

14.1.3.2.2 Mapping to TC component parameters 

The mapping of parameters for the TC component services is defined in subclause 14.1.1.4.2 with the following 
qualifications. 

The Timeout Parameter of the TC-INVOKE service is set according to clauses 6. 

14.1.4 gprsSSF-gsmSCF interface 
14.1.4.1 Normal procedures 

14.1.4.1.1 TC-dialogues and relationships 

The GPRS dialogue can consist of multiple consecutive TC-dialogues. A GPRS dialogue is identified by a GPRS- 
ReferenceNumber consisting of the originationReference and the destinationReference. One GPRS -Reference is 
assigned by the SGSN and shall be unique within this SGSN. The other GPRS -Reference is assigned by the gsmSCF 
and shall be unique within this gsmSCF. 

The rC-dialogues are closed and (re)opened whenever necessary. 

14.1.4.1.2 Use of the GPRS Reference 

For the use of CAP defined GPRS -Re fere nceN umber, see also the ASN.l notation in the subclause 8.1. 

When the gprsSSF sends the first operation for a new GPRS dialogue (InitialDPGPRS), the gprsSSF shall include a 
GPRS Reference Number in the TC message. This GPRS Reference Number shall consist of the SGSN Process Id as 
originationReference, which is internally allocated by the gprsSSF. This number is used by the gprsSSF to associate an 
incoming TC message with an internal GPRS Process. 

When the gsmSCF has received the InitialDPGPRS operation, it shall store the SGSN Process ID and allocate an SCF 
Process Id which is used by the gsmSCF to associate an incoming TC message with an internal gsmSCF Process. 

The gsmSCF shall include the GPRS Reference Number in the first TC-CONTINUE message, SGSN Process Id in 
destinationReference and SCF Process Id in originationReference, returned to the gprsSSF. 

When the gprsSSF receives the first TC message from the gsmSCF for this GPRS dialogue, the gprsSSF shall store the 
gsmSCF Process Id together with the SGSN Process Id. 
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From here onwards all the TC messages that open a new TC dialogue shall include the GPRS Reference Number 
consisting of the originationReference and the destinationReference to associate the internal process in the origination 
entity and the destination entity, respectively, until the end of the relationship between these processes. 

For any TC-CONTINUE in the existing TC dialogue, transporting the GPRS Reference Number is not needed except 
for the first response after the InitialDPGPRS operation. 

14.1.4.1.3 gprsSSF-to-gsmSCF messages 

The present subclause defines the normal procedures for TC messages from the gprsSSF to the gsmSCF. 

gprsSSF FSM related messages 

A GPRS dialogue and a TC dialogue shall be established when the gprsSSF FSM transits from the state "Idle" to the 
state "Waiting_for_Instructions". The InitialDPGPRS operation shall be transmitted in the same TC message, i.e. TC- 
BEGIN. It shall contain the GPRS -Reference as assigned by the SGSN in the originationReference. The gprsSSF may 
intiate the subsequent TC dialogues for this GPRS dialogue with the following operations: 

- ApplyChargingReportGPRS 

- EntityReleasedGPRS 

- EventReportGPRS 

For the establishment of a new TC dialogue within the context of the current GPRS dialogue, the gprsSSF may apply 
one of the following mechanisms: 

(1) the gprsSSF shall memorise the gsmSCF address used in the first response message to the InitialDPGPRS and use 
it to open the new TC dialogue; 

(2) the gprsSSF shall use the gsmSCF address from GPRS-CSI to open the new TC dialogue. 

The gsmSCF shall memorise the gprsSSF address received along with the InitialDPGPRS and use it for the opening of 
new TC dialogues within the context of the current GPRS dialogue. 

The gsmSCF may open subsequent TC dialogues with the following CAP Operations: 

- ActivityTestGPRS; 

- ApplyChargingGPRS; 

- CancelGPRS; 
FurnishCharginglnformationGPRS ; 

- ReleaseGPRS; 

- RequestReportGPRSEvent; 

- SendCharginglnformationGPRS. 

The CAP Operation that opens a TC dialogue shall be sent with a TC-BEGIN request primitive. This message shall 
contain the GPRS -Re fere nceNumber assigned by the sender of this message in the originationReference. If the 
operation opens a subsequent TC dialogue, then this message shall contain also the previously received 
destinationReference. If an operation opens a GPRS dialogue, then the TC message reply shall contain the 
originationReference as assigned by the sender, i.e. the gsmSCF. 

The TC dialogue shall be closed for the idle periods, i.e. when the gprsSSF FSM transits from the state 
"Waiting_for_Instructions" to the state "Idle", if the gprsSSF FSM is in the state "Monitoring" and has received all 
replies or time-outs for the operations sent, after standalone operations of the gsmSCF in Monitoring state if gprsSSF 
FSM does not transit to the state "Idle" (ActivityTestGPRS, ApplyChargingGPRS, CancelGPRS, 
FurnishCharginglnformationGPRS, RequestReportGPRSEvent, SendCharginglnformationGPRS), or at the end of a 
GPRS dialogue. 

Each TC dialogue shall be terminated by the gprsSSF using TC-END (basic end). The following operations can cause 
the end of the GPRS dialogue: 
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- ContinueGPRS; 

- ConnectGPRS; 
ApplyChargingReportGPRS result; 

- EntityReleasedGPRS rersult; 

- EventReportGPRS (EDP-N) result; 

- CancelGPRS; 

- ReleaseGPRS; 

RequestReportGPRSEvent (disarming of DPs). 

When the gprsSSF FSM makes a non-error case state transition to the state "Idle" and there is one or more pending 
operation and TC dialogue is established, TC dialogue may be terminated by TC-END primitive with zero 
component(s) after all pending operations have been sent. When the gprsSSF sends the last EventReportGPRS, 
EntityreleasedGPRS or ApplyChargingReportGPRS, then aftrer reception of the result or error, the GPRS dialogue may 
be ended from the gprsSSF by a TC-END request primitive with basic end. 

In the case that there is no pending operation, result nor error, and TC dialogue is established, TC dialogue shall be 
terminated by a TC-END primitive with zero component. 

In the case where a PDP Context release or detach is initiated by any other entity than a gsmSCF, the gprsSSF shall end 
a GPRS dialogue with the EntityReleasedGPRS operation if the gprsSSF has no armed DP to report nor pending 
ApplyChargingReportGPRS which should reported. 

In the case of overlapping dialogues for the same GPRS dialogue the gsmSCF opened TC dialogue is aborted by the 
gprsSSF with the abort reason overlapping-dialogue as specified in subclause 5.7. This abort reason is used to indicate 
to the gsmSCF that a specific instance already has a TC dialogue open. It is typically obtained when both the gsmSCF 
and gprsSSF open a new dialogue at the same time. While the gprsSSF waits for a response to an operation sent in TC- 
BEGIN it may receive an operation from the gsmSCF in TC-BEGIN. In such cases the dialogue opened by the gprsSSF 
is maintained and the dialogue opened by the gsmSCF is aborted with this abort reason. 

gprsSSME FSM related messages 

The following procedures shall be followed: 

The TC dialogue shall be terminated by a TC-END primitive with zero components after the Activity TestGPRS 
Return Result is sent. 

1 4. 1 .4. 1 .4 gsmSCF-to-gprsSSF messages 

The present subclause defines the normal procedures for TC messages from the gsmSCF to the gprsSSF. 

In the case of overlapping dialogues for the same relationship the gsmSCF opened dialogue is closed by the gprsSSF as 
specified in subclause 5.7. The gsmSCF shall first respond normally to the operations sent by the gprsSSF, and then 
decide on the further actions. 

SCME-FSM related messages 

The operations sent from the SCME-FSM shall be issued according to the following procedures: 

A new subsequent TC dialogue is established when the Activity TestGPRS operation is sent. 

14.1.4.2 Abnormal procedures 

1 4. 1 .4.2. 1 gsmSCF-to-gprsSSF messages 

The present subclause defines the abnormal procedures for TC messages from the gsmSCF to the gprsSSF. 

Considering that the gprsSSF does not have the logic to recover from error cases detected on the gsmSCF-gprsSSF 
interface, the following shall apply: 
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Operation errors and rejection of TC components shall be transmitted to the gprsSSF with a TC-END request 
primitive, basic end. 

-The GPRS dialogue shall be closed. 

- The gprsSSF shall apply Default GPRS Handling from the valid CSI to the PDP Context or GPRS Session. 

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC -CONTINUE 
indication primitive, then the gprsSSF shall abort the dialogue with a TC-U-ABORT request primitive and shall apply 
Default GPRS Handling from the valid CSI to the PDP Context or GPRS Session. 

14.1.4.2.2 gprsSSF-to-gsmSCF messages 

The present subclause defines the abnormal procedures for TC messages from the gprsSSF to the gsmSCF. 

Operation errors and rejection of TC components shall be transmitted to the gsmSCF according to the following rules: 

The TC dialogue shall be maintained when the preceding message, which contained the erroneous component, 
indicated that the dialogue shall be maintained. I.e. the error or reject shall be transmitted with a 
TC-CONTINUE request primitive. 

On receipt of an ERROR or REJECT component the gsmSCF decides on further processing. It may either 
continue, explicitly end or abort the TC dialogue. If the TC dialogue is closed due to such error, then the GPRS 
dialogue shall also be closed. 

on expiration of application timer Tssf, the TC dialogue shall be terminated by means of by TC-U-ABORT 
primitive with an Abort reason. The GPRS dialogue shall be closed. 

If the error processing in the gprsSSF leads to the case where the gprsSSF is not able to process further gsmSCF 
operations while the TC dialogue is to be maintained, then the gprsSSF aborts the TC dialogue with a TC-END request 
primitive with basic end or a TC-U-ABORT request primitive, depending on whether any pending ERROR or REJECT 
component is to be sent or not. 

The gprsSSF can end a TC dialogue with a TC-U-ABORT request primitive in the following case: 

Any entity other than the gsmSCF initiates closure of the GPRS dialogue, and 

The gprsSSF has no pending reports, and 

The gprsSSF has no armed EDP to notify the gsmSCF that the GPRS dialogue has been closed. 
For an alternative method, see subclause 14.1.7.1.1. 

14.1 .4.2.3 Default GPRS Handling 

If a TC dialogue is closed due to unrecoverable TC/protocol error (does not apply to the overlapping TC dialogues), or 
aborted by the gsmSCF, or at the Tssf expiry, then the gprsSSF shall check the applicable Default GPRS Handling 
parameter of the GPRS -CSI. In this context the applicable Default GPRS Handling is the one that corresponds the TDP 
that opened the GPRS dialogue. The same default handling shall apply to all state models that are controlled by the 
particular GPRS dialogue. 

14.2 Services assumed from SCCP 

The present subclause describes the services required from the SCCP that may be used by the CAMEL applications for 
the CAMEL Application Part (CAP) used between the gsmSSF, assisting gsmSSF, gsmSRF, gprsSSF, and gsmSCF. 

The following SCCP revisions are supported by CAP: 

- Signalling Connection Control Part, Signalling System no. 7 CCITT ("Blue Book SCCP") 

Signalling Connection Control Part, Signalling System no. 7 ITU-T Recommendation Q.71 1 to Q.716 ("White 
Book SCCP") 

NOTE: Support of White Book SCCP at the receiving side shall be mandated from 00:01hrs, 1st July 2002(UTC). 
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ANSI Tl.l 12-1996 [91]: "American National Standards for Telecommunications- Signalling System Number 7 
(SS7) - Signalling Connection Control Part (SCCP)". 

When CAP uses White Book SCCP to send a message, and SCCP segments the message into one or more XUDT 
messages, then the transmission of this message may fail. 

Failure will occur when the destination SCCP, or any intermediate SCCP, does not support White Book SCCP. 

Support of ANSI Tl.l 12-1996 [91] SCCP applies to PLMNs in North America only. Interworking between a PLMN in 
North America and a PLMN outside North America will involve a STP to translate between ANSI SCCP and ITU- 
T/CCITT SCCP. 

14.2.1 Normal procedures 

The SCCP forms the link between the TC and the MTP and provides (in conjunction with the MTP) the network 
services for the CAMEL applications. The network services provided allow the signalling messages sent by the 
application to the lower layers to be successfully delivered to the peer application. 

1 4.2.2 Service functions from SCCP 
14.2.2.1 SCCP connectionless services 

The services described are those given in the SCCP ITU-T recommendations Q.71 1 to Q.716 should be consulted to 
identify possible interworking and compatibility issues between the different SCCP versions. 

The following Connection-less services are expected from the SCCP: 

a) Network Addressing to enable signalling connections between SCCP users; 

b) Sequence Control to enable the SCCP users to invoke "sequence guaranteed" or "sequence not guaranteed" 
options for a given stream of messages to the same destination; 

c) Segmentation/reassembly of large user messages (for "White Book SCCP" only); 

d) Return Option to enable the SCCP users to invoke "discard message on error" or "return message on error" for a 
given message not able to be delivered by the SCCP to the destination SCCP user, due to routeing or 
segmentation/re-assembly failure; 

e) Congestion control. 

The primitives used for the above services are given below. 

The N-UNITDATA request and N-UNITDATA indication primitives are used to send and receive data. The parameters 
of these primitives include the Called and Calling Addresses, Sequence Control, Return Option and User Data with the 
addressing parameters always mandatory. 

The N-NOTICE indication primitive is used to return undelivered data if return option is set and a 
routeing/segmentation error occurs. 

14.2.2.1.1 Sub-System Number (SSN) 

The use of SSN is a network operator option and values for intra-PLMN usage are network specific. A CAP SSN has 
been reserved for inter-PLMN use, as defined in 3GPP TS 23.003 [5]. 

14.2.2.1.2 Addressing 

The addressing elements consist of information contained within the Calling and the Called Party Addresses which are 
sent by the application to the lower layers. 

The application expects the SCCP to route messages by either (a) the use of the Destination Point Code (DPC) plus the 
Subsystem Number (SSN), or (b) the use of the GT plus optionally the SSN. The application also specifies to the lower 
layer whether to route the message on the DPC or the GT. 
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Method (a) above may be used when the application is aware of the destination point code and the destination SSN 
located at that point code to which the message is to be delivered. Within a national network different SSNs, according 
to ITU-T Recommendation Q.713 [42], may be allocated for the different network specific applications, e.g. a SSN may 
be allocated for a gsmSCF functionality. 

Method (b) above may be used when a message is to be delivered to a SCCP-user which can be identified by the 
combination of the elements within the GT. An example of the use of this method is when messages have to be 
delivered between different networks. This method may be used since the originating network is unaware of the point 
code and SSN's allocations within the destination network. The network that determines the end-node to which the 
message is to be delivered has to perform a GT Translation to derive the destination Point Code and the SSN. If 
optionally the original address contained the SSN, then this may be used as the destination SSN, or the translation may, 
if required, provide an appropriate new SSN. 

When GT is used for addressing, the CAMEL application expects that the SCCP supports the following elements as 
defined in ITU-T Recommendation Q.713 [42]: 

Address Indicator: 

The application will set this indicator to indicate one or any combination of the elements "signalling point code, GT, 
subsystem number" in the address information octets. 

GT Indicator: 

This indicator specifies the method employed for the formatting of the address information. There are four values 
(1 to 4), for example, the value 4 indicates that the format includes the numbering plan, the nature of the address 
indicator and the translation type. The format with the indicator value 4 is always used for internetwork connections. 

Translation Type: 

The Translation Types are defined within ITU-T Recommendation Q.713 [42]. 

Numbering Plan: 

1) The proposed "generic numbering plan" is described within the ITU-T Recommendation Q.713 [42]. This 
numbering plan identifies the SCCP nodes or SCCP subsystems unambiguously such that messages may be 
efficiently routed within one or more networks, and is particularly useful when used in the Calling Address for 
the sending of a response message back to the originating node. This is achieved by having an international and a 
national part in the generic numbering plan. For response messages the responding node analyses the 
international part of the generic numbering plan to determine the gateway node to which the response is to be 
routed. Having routed to the gateway node, the national part (which was populated within the originating 
network) is analysed to determine the originating node within the originating network. 

2) A numbering plan which would define particular nodes based specifically on services is outside the scope of 
CAMEL. 

3) The SCCP caters for a number of other numbering plans (e.g. ISDN, Mobile etc. numbering plans). The whole 
range catered for is shown in [?]. These may be used by CAMEL applications if deemed suitable. 

Encoding Scheme: 

This identifies the encoding scheme employed by the application and is generally BCD encoded with odd or even 
number of digits. 

GT Address Information: 

These are the actual address digits supplied by the application and may be BCD digits or encoded as indicated by the 
encoding scheme. 

The network provider must ensure that any change of GT value during translation preserves any CAP specific 
information contained in the initial GT value. 

This requirement applies to all interfaces, not just those used for internetworking. 

If route on SSN is to be supported from the originating node, then an ITU-T non-zero internationally standardised 
SSN is required for international internetworking. 
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In the absence of a ITU-T standardised non-zero SSN for CAP services, the use of route on GT is mandatory from 
the origin node to the network containing the destination node. 

When the SCCP of CCITT Signalling System No. 7 is used, the format and coding of address parameters carried by the 
SCCP for that purpose shall comply with ITU-T Recommendation Q.713 [42] with the following restrictions: 

1) Intra-PLMN addressing 

For communication between entities within the same PLMN, the use of SCCP addressing is network specific, 
and method (a) and (b) are both applicable. 

2) Inter-PLMN addressing 

method (b) with the mandatory SSN is applicable only with the following format: 

i) Called Party Address 

- SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP 
TS 23.003 [5]; 

Point Code indicator = 0; 

Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and 
nature of address indicator); 

Translation type = (Not used); 

Routing indicator = (Routeing on global title); 

The format is also described in the table 14-2 below (for NP=1, NAI=4): 

Table 14-2: Called Party Address format 



8 


7 


6 I 5 | 4 | 3 


2 


1 







Rl = 


GTI=4(0100) 


SSNI = 1 


PCI = 


Octet 1 


SSN = a value for CAP as specified in 3GPP TS 23.003 [5] 


Octet 2 


Translation type = 


Octet 3 


Numbering plan = 1 (E.164) | Encoding scheme = 1 or 2 


Octet 4 





Nature of address indicator = 4 (International) 


Octet 5 


Country code digit 2 (if present) 


Country code digit 1 


Octet 6 


National Destination Code (NDC) Digit 1 


Country code digit 3 (if present) 


Octet 7 


NDCdigit3 (if present) 


NDC digit 2 (if present) 


Octet 8 


NDC digit 5 (if present) 


NDC digit 4 (if present) 


Octet 9 


Equipment idntification digit 2 


Equipment idntification digit 1 


Octet 10 








filler = (if needed) 


Equipment idntification digit m 


Octet n 



Note Country code, National Destination Code, and SN(equipment id) are provided as example, so each digit 

may differ for each Inter-PLMN addressing case, (e.g., there is a case where only CC digit 1 shall be used). 
See ITU-T Recommendation Q.713 [42] for translation rules. 

ii) Calling Party Address 

- SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP TS 
23.003 [5]; 

Point code indicator = 0; 

Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and 
nature of address indicator); 

Translation type = (Not used); 

Routing indicator = (Routeing on Global Title). 
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The format is also described in the table 14-3 below (for NP=1, NAI=4): 

Table 14-3: Calling Party Address format 



8 


7 


6 I 5 | 4 | 3 


2 


1 







Rl = 


GTI=4 


SSNI = 1 


PCI = 


Octet 1 


SSN = a value for CAP as specified in 3GPP TS 23.003 [5] 


Octet 2 


Translation type = 


Octet 3 


Numbering plan = 1 (E.164) | Encoding scheme = 1 or 2 


Octet 4 


| Nature of address indicator = 4 (International) 


Octet 5 


Country code digit 2 (if present) 


Country code digit 1 


Octet 6 


National Destination Code (NDC) Digit 1 


Country code digit 3 (if present) 


Octet 7 


NDCdigit3 (if present) 


NDC digit 2 (if present) 


Octet 8 


NDC digit 5 (if present) 


NDC digit 4 (if present) 


Octet 9 


Equipment idntification digit 2 


Equipment idntification digit 1 


Octet 10 








Filler = (if needed) 


Equipment idntification digit m 


Octet n 



Note Country code, National Destination Code, and SN(equipment id) are provided as example, so each digit 

may differ for each Inter-PLMN addressing case, (e.g., there is a case where only CC digit 1 shall be used). 
See ITU-T Recommendation Q.713 [42] for translation rules. 

When the SCCP of ANSI Signalling System No. 7 is used, the format and coding of address parameters carried by the 
SCCP for the purpose of signalling transfer shall comply with ANSI Recommendation Tl.l 12-1996 [91] with the 
following restrictions: 

1) Intra-PLMN addressing 

For communication between entities within the same PLMN, the use of SCCP addressing is network specific. 

2) Inter-PLMN addressing 

a) Called Party Address 

SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP 
TS 23.003 [5]; 

Point Code indicator = 0; 

Global title indicator = 0010 (Global title includes translation type); 

the Translation Type (TT) field shall be coded according to the content of the address information as 
follows: 

TT = 9 (decimal), if IMSI is included; or 

TT = 14 (decimal), if MSISDN is included; or 

TT =10 (decimal), if a Network Element address is included. (If TT=10, then Number Portability is not 
applicable, if TT=14, then Number Portability is applicable) 

Routing indicator = (Routeing on global title); 

b) Calling Party Address 

SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP 
TS 23.003 [5]; 

Point code indicator = 0; 

Global title indicator = 0010 (Global title includes translation type); 

the Translation Type (TT) field shall be coded according to the content of the address information as 
follows: 

TT = 9 (decimal), if IMSI is included; or 
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TT = 14 (decimal), if MSISDN is included; or 

TT =10 (decimal), if a Network Element address is included. (If TT=10, then Number Portability is not 
applicable, if TT=14, then Number Portability is applicable) 

Routing indicator = (Routeing on Global Title). 

14.2.2.1.3 Sequence control 

The application will specify whether SCCP protocol class or 1 is required. Class provides a basic connection-less 
service where the sequence of message delivery is not guaranteed. Class 1 connection-less service provides a 
guaranteed sequence delivery of messages (with the same called address) for a given stream of messages. Class 1 shall 
be requested by any application that can send more than 1 TC message to its peer (consecutive TR-CONTINUE) before 
receiving a response from its peer (TR-CONTINUE or TR-END). 

On receipt of a TC-RESULT-NL indication, the TC-USER shall request the transfer of a reject component using TC-U- 
REJECT request primitive, with the appropriate problem code (mistyped parameter). 

The return option may be used if requested by the application (Network Operator to determine). 

14.2.2.1.4 Return on error 

Return on Error mechanism may be required by the CAMEL applications such that the application is aware of messages 
that have not been delivered to the destination by the SCCP. The return option allows the return of the message that was 
not delivered due to routeing or segmentation/re-assembly failure back to the issuing user. This return option may be 
required in all segments of a long message or only in the first segment by the CAMEL applications. 

If the return option is invoked by the application and the message is not delivered, then the SCCP specifies the "return 
reason" as specified in ITU-T Recommendation Q.713 [42]. The N-NOTICE primitive is used to return the undelivered 
message to the originating user. 

14.2.2.1.5 Segmentation /reassembly 

The application expects that since the SCCP can send up to 260 octets of user data (including the address information 
and TC-message) in a UDT message (248 octets in a XUDT message performing segmentation and congestion control), 
segmentation is available for long user messages. 

Also the SCCP is expected to perform the reassembly function on received segmented messages and deliver the 
reassembled message to the user. 

However, it should be noted that even though the theoretical maximum size of SCCP-user data and addresses that can 
be segmented by the SCCP is 3 968 octets, the SCCP-user would limit the length to about 2 560 octets to allow for the 
largest known addresses. Note that the application must also allow for the octets used for the TC-message in the 2 560 
octets. 

The CAMEL application does not expect the SCCP to segment the long message into more than 16 segments. 

14.2.2.1.6 Congestion control 

To help control of possible congestion that might occur in the lower layers the application may assign a value to 
indicate the importance of the message. The use of this parameter requires the use of SCCP (1997) ITU-T 
Recommendations. 

Also there exist other congestion control mechanisms as indicated below in SCCP Management. 

These congestion control methods are network operator option in the case of intra-PLMN network signalling, and shall 
not be used in the case of inter-PLMN network signalling. 

14.2.2.2 SCCP connection oriented services 

The use by CAMEL applications for the Connection-oriented services is outside the scope of CAMEL. 
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14.2.2.3 SCCP management 

The subsystems used within the CAMEL application expect the SCCP to provide management procedures to maintain 
network performance by re-routeing in the event of failure of a subsystem, and in the case of network congestion by use 
of the congestion handling procedure. These procedures have appropriate interactions with the SCCP user as described 
in ITU-T Recommendations Q.713 [42] and ITU-T Recommendation Q.714 [43]. 

To achieve the above the SCCP is expected to perform the following procedures: 

Signalling point status management (which include the signalling point prohibited, signalling point allowed, 
signalling point congested, and local MTP availability sub procedures). 

Subsystem status management (which include the subsystem prohibited, subsystem allowed, and subsystem 
status test sub procedures). 

Co-ordinated state change (a procedure which allows a duplicated subsystem to be withdrawn from service 
without affecting the performance of the network). 

These SCCP management procedures are network operator option in the case of intra-PLMN network signalling, and 
shall not be used in the case of inter-PLMN network signalling. 
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Annex A (normative): 

Mapping between CAP and ISUP 

A.1 InitialDP operation 

Table A.1 



ISUP message 
IAM(Note1) 


CAP Operation 
InitialDP 


Called party number (note 6) 


CalledPartyNumber 


Calling party number 


CallingPartyNumber 


Calling party's category 


CallingPartysCategory 


Location number 


LocationNumber 


Original called number 


OriginalCalledPartylD 


User teleservice information (1 st priority) 

High layer compatibility IE contained in access transport 
(2 nd priority) (Note 2) 


HighLayerCompatibility 


High layer compatibility IE contained in access transport 
(Note 2) 


HighLayerCompatibility2 


Low Layer compatibility IE contained in access transport 
(note 4) 


LowLayerCompatibility 


Low Layer compatibility IE contained in access transport 
(note 4) 


LowLayerCompatibility2 


Generic number "additional calling party number" 


AdditionalCallingPartyNumber 


User service information prime (1 st priority) 
User service information (2 nd priority) (Note 3) 


BearerCapability 


User service information (Note 3) 


BearerCapability2 


Redirecting number 


RedirectingPartylD 


Redirection information 


Redirectionlnformation 


Call diversion treatment indicators 


ServicelnteractionlndicatorsTwo.Call diversion treatment 
indicators 


Conference treatment indicators 


ServicelnteractionlndicatorsTwo. Conference treatment 
indicators 


User-to-user indicators (Note 5) 


UU-Data.UUIndicator 


User-to-user information (Note 5) 


UU-Data.UUI 



NOTE 1: Optional parameters may be absent, i.e. they are only mapped only if these parameters are available at the 
DP. 

NOTE 2: If two high layer compatibility information elements are contained in the access transport parameter, then 

the second information element, carrying the preferred HLC, is mapped to the CAP highLayerCompatibility 
parameter, and the first information element, carrying the less preferred HLC, is mapped to the CAP 
highLayerCompatibility2 parameter. 

NOTE 3: If User service information prime and User service information are present, then one of the following two 
mapping rules shall be applied. The principles for the choice of mapping rule are specified in 
3GPPTS 23.078 [7]. 

One of User service information prime or User service information is mapped to Bearer Capability. 

User service information prime is mapped to BearerCapability and User service information is mapped 
to Bearer Capability2. 

NOTE 4: If two low layer compatibility information elements are contained in the access transport parameter, then the 
first information element, carrying the preferred LLC, is mapped to the CAP lowLayerCompatibility 
parameter, and the second information element, carrying the less preferred LLC, is mapped to the CAP 
lowLayerCompatibility2 parameter. 



ETSI 



3GPP TS 29.078 version 8.2.1 Release 8 



212 



ETSI TS 129 078 V8.2.1 (2010-04) 



NOTE 5: If present in ISUP IAM, user-to-user indicators and user-to-user information may optionally be mapped into 
the InitialDP Operation. 

NOTE 6: For trunk originating calls using overlap signalling, the called party number may contain partial address 
digits. 



A.1 .1 EventReportBCSM Operation 



Table A.1.1 



ISUP message 
SAMs(Notel) 


CAP Operation 
EventReportBCSM 


Subsequent number 


CalledPartyNumber 



NOTE 1: For trunk originating calls using overlap signalling, subsequent address digits may be reported to the 
gsmSCF in EventReportBCSM, if requested by the gsmSCF with the "Collect Information" operation. 



A.2 ContinueWithArgument operation 

Table A.2 illustrates the mapping of parameters received in the ContinueWithArgument operation to parameters sent in 
the ISUP IAM to the succeeding exchange. Parameters which were received in the ISUP IAM and are not replaced by 
parameters of the ContinueWithArgument operation are treated according to the normal procedures. 

For trunk originating calls using overlap signalling, the called party number in ISUP IAM may contain partial address 
digits. Any address digits received in SAMs, before the ISUP IAM is sent out, may also be included in the called party 
number parameter. Any address digits received in SAMs, after the ISUP IAM is sent out and before an ISUP ACM is 
received, shall be passed on to the succeeding exchange as received. 

On sending of the ISUP IAM the awaiting address complete timer is started. If the timer expires, then the call is 
released in both directions and an appropriate indication is returned to the calling subscriber. 

Table A.2 



CAP Operation ContinueWithArgument (Note 1) 


ISUP message IAM 


originalCalledPartylD 


Original called number 


callingPartysCategory 


Calling party's category 


redirectingPartylD 


Redirecting number 


redirectionlnformation 


Redirection information 


genericNumbers 


Generic number (Note 2) 


servicelnteractionlndicatorTwo 


See Table A.4 


cug-lnterlock 


Closed user group interlock code 


cug-OutgoingAccess 


Optional forward call indicators (Note 3) 



NOTE 1: Optional parameters may be absent, i.e. they are mapped only if received. 

NOTE 2: The set of generic numbers received in the genericNumbers parameter is mapped to the appropriate number 
of Generic Number parameters in the ISUP IAM. This shall be performed irrespective of the value of the 
screening indicator in the ISUP calling party number. 

NOTE 3: The cug-Outgoing Access is mapped to the Closed User Group indicator which is carried in bits A & B of the 
Optional forward call indicators. 



A.3 Connect operation 



On receipt of a Connect operation from the gsmSCF the called party number used for routeing is derived from the 
destinationRoutingAddress (see Table A.3). If the triggering of the CAMEL service was made for a mobile terminating 
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call in the GMSC or VMSC or for a mobile forwarded call, then an ISUP ACM shall be sent to the preceding exchange. 
The encoding of the backward call indicators in the ISUP ACM is specified in 3GPP TS 09.12 [1]. 

On receipt of a Connect operation from the gsmSCF for a trunk originating call, the called party number used for 
routeing is derived from the destinationRoutingAddress (see Table A. 3) and an ISUP ACM is sent to the preceding 
exchange (in an overlap signalling scenario this will prevent any further SAMs being sent by the preceding exchange). 

Table A. 3 illustrates the mapping of parameters received in the Connect operation to parameters sent in the ISUP IAM 
to the succeeding exchange. Parameters which were received in the ISUP IAM and are not replaced by parameters of 
the Connect operation are treated according to the normal procedures. 

On sending of the ISUP IAM the awaiting address complete timer is started. If the timer expires, then the call is 
released in both directions and an appropriate indication is returned to the calling subscriber. 

Table A.3 



CAP Operation 
Connect (Note 1) 


ISUP message 
IAM 


DestinationRoutingAddress 


Called party number 


OriginalCalledPartylD 


Original called number 


callingPartysCategory 


Calling party's category 


redirectingPartylD 


Redirecting number 


redirectionlnformation 


Redirection information 


GenericNumbers 


Generic number (Note 2) 


ServicelnteractionlndicatorTwo 


See Table A.4 


Cug-lnterlock 


Closed user group interlock code 


cug-OutgoingAccess 


Optional forward call indicators (Note 3) 



NOTE 1: Optional parameters may be absent, i.e. they are mapped only if received. 

NOTE 2: The set of generic numbers received in the genericNumbers parameter is mapped to the appropriate number 
of Generic Number parameters in the ISUP IAM. This shall be performed irrespective of the value of the 
screening indicator in the ISUP calling party number. 

NOTE 3: The cug-Outgoing Access is mapped to the Closed User Group indicator which is carried in bits A & B of the 
Optional forward call indicators. 

Table A.4 - Mapping of the CAP Connect and ContinueWithArgument operation servicelnteractionlndicatorsTwo to 
ISUP. 
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Table A.4 



CAP 


ISUP parameter in 


Servicelnteractionlndicators 


ACM/CPG/CON/ANM/REL 


IAM 




— 


Call diversion treatment indicators 
parameter 


Call to be diverted indicator 




Call to be diverted indicator 


- call diversion allowed 




- no indication 


- call diversion not allowed 




- call diversion allowed 

- call diversion not allowed 




... 


Conference treatment indicators 
parameter 


Conference at DLE accept, ind. 




Conference acceptance ind. 


- accept conference request 




- no indication 


- reject conference request 




- accept conference request 

- reject conference request 


Calling party restriction indicator 


... 


Calling party number address 
presentation restricted indicator 


- no IN impact 




- no impact 


presentation restricted 




presentation restricted 




ACM/CPG/CON/ANM: Conference 


... 




treatment indicators parameter 




Conference at OLE accept, ind. 


Conference acceptance ind. 




- accept conference request 


- no indication 




- reject conference request 


- accept conference request 

- reject conference request 






REL, busy cause 


... 


Call completion treatment indicator 


Diagnostig field 




- accept CCBS service request 


- CCBS possible 




reject CCBS service request 


- CCBS not possible 




Connected number treatment indicator 


Note 3 




- no IN impact 






- presentation restricted 






- present called IN number 






- present called IN number restricted 







NOTE 3: 

If "no IN impact" was received for Connected number treatment indicator in the servicelnteractionlndicatorsTwo, 
then a connected number parameter and a generic number parameter "additional connected number" are 
passed on unchanged. 

If "presentation restricted" was received for Connected number treatment indicator in the 
servicelnteractionlndicatorsTwo, then: 

a) If a connected number parameter has been received in the ISUP ANM or ISUP CON, then the address 
presentation restricted indicator is set to "presentation restricted". 

b) If a generic number parameter "additional connected number" has been received in the ISUP ANM or ISUP 
CON, then the address presentation restricted indicator is set to "presentation restricted". 

c) If a redirection number parameter has been received, then a redirection number restriction parameter is sent 
in the ISUP ANM with bits AB set to "presentation restricted". 

If "present called IN number" was received for Connected number treatment indicator in the 
servicelnteractionlndicatorsTwo, then: 

a) If a connected number parameter has been received in the ISUP ANM or ISUP CON, then the connected 

number parameter is modified as follows: 

nature of address indicator and numbering plan indicator are encoded as received in the called party number 
of the ISUP IAM, 

address presentation restricted indicator: 00 (presentation allowed), 
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address signals: as received in the called party number and possible subsequent number parameters, until 
the ISUP ACM was sent. 

b) A generic number parameter "additional connected number" is deleted from the message, if applicable, 

c) A redirection number parameter is deleted from the relevant messages, if applicable. 

If "present called IN number restricted" was received for Connected number treatment indicator in the 
servicelnteractionlndicatorsTwo, then: 

a) If a connected number parameter has been received in the ISUP ANM or ISUP CON, then the connected 
number parameter is modified as follows: 

nature of address indicator and numbering plan indicator are encoded as received in the called party number 
of the ISUP IAM, 

address presentation restricted indicator: 01 (presentation restricted), 

address signals: as received in the called party number and possible subsequent number parameters, until 
the ISUP ACM was sent. 

b) A generic number parameter "additional connected number" is deleted from the message, if applicable, 

c) A redirection number parameter is deleted from the relevant messages, if applicable. 



A.4 AssistRequestlnstructions operation 

If an ISUP IAM is received at an assisting SSP containing an assisting gsmSSF or at an IP containing a gsmSRF, then 
an AssistRequestlnstructions operation is sent to the gsmSCF. The correlationID parameter in the 
AssistRequestlnstructions operation can contain: 

a) the CorrelationID digits extracted from the ISUP IAM Called Party Number, 

b) the whole Called Party Number received in the ISUP IAM (CorrelationID digits extracted at gsmSCF), 

c) the contents of the ISUP IAM CorrelationID parameter. 

In the case where the gsmSCF and the assisting gsmSSF are both in the HPLMN and ISUP 97 is supported then any of 
these mechanisms may be used. 

In the case where the gsmSCF and the assisting gsmSSF are both in the HPLMN and ISUP 97 is not supported then 
mechanisms a) and b) may be used. 

In the case where the gsmSCF is in the HPLMN and the assisting gsmSSF is in the VPLMN then only mechanism b) 
may be used when an all-ISUP 97 signalling path cannot be guaranteed. Mechanism a) may be used if bilateral 
agreements on the format of the information transferred in the ISUP IAM Called Party Number are defined between the 
HPLMN and the VPLMN. 

In the case where the gsmSCF is in the HPLMN and the assisting gsmSSF is in the VPLMN then mechanism c) may 
only be used if an all-ISUP 97 signalling path can be guaranteed between the HPLMN and the VPLMN. 



A.5 ConnectToResource operation 

On receipt of a ConnectToResource operation from the gsmSCF, the gsmSRF is connected to the call, to facilitate User 
Interactive dialogue with the user. 
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If the User Interactive dialogue is to be performed at a forwarding MSC or at a terminating MSC (GMSC or VMSC), 
then an ISUP ACM shall be sent to the preceding exchange. The encoding of the backward call indicators in the ISUP 
ACM is specified in 3GPP TS 09.12 [1], with the Optional Backward Call Indicators indicating "in-band information or 
an appropriate pattern is now available". 

If the User Interactive dialogue is to be performed at a forwarding MSC or at a terminating MSC (GMSC or VMSC), 
then when the gsmSRF indicates through-connection and the ConnectToResource operation indicates that a bothway 
throughconnection is required, an ISUP ANM shall be sent to the preceding exchange if answer has not previously been 
sent. As a network operator/equipment vendor option an ISUP CPG message may be sent if ISUP ANM has already 
been sent. 



A.6 EstablishTemporaryConnection operation 

On receipt of an EstablishTemporaryConnection operation from the gsmSCF then if the triggering of the CAMEL 
service was made for a mobile terminating call in the GMSC or VMSC or for a forwarded call, then an ISUP ACM 
shall be sent to the preceding exchange. The encoding of the backward call indicators in the ISUP ACM is specified in 
3GPP TS 09.12 [1], In addition, an ISUP IAM shall be sent to the succeeding exchange. 

Table A. 5 illustrates the mapping of parameters received in the EstablishTemporaryConnection operation to parameters 
sent in the ISUP IAM to the succeeding exchange. On sending of the ISUP IAM the awaiting address complete timer is 
started. If the timer expires, then the call is released in both directions and an appropriate indication is returned to the 
calling subscriber. 

Table A.5 



CAP Operation 
EstablishTemporaryConnection 


ISUP message 
IAM 


AssistingSSPIPRoutingAddress (note 1) 


Called party number 


CorrelationID 


Correlation id (note 2) 


Scfld 


GsmSCF id (note 2) 


OriginalCalledPartylD 


Original called number (note 3) 


CallingPartyNumber 


Calling party number (note 3) 



NOTE 1: The AssistingSSPIPRoutingAddress parameter may also include a Hex B digit, in order to delineate the 
boundary between digits used for routeing and digits forming part of the SCFiD and/or CorrelationID. 

NOTE 2: These optional parameters may be absent, i.e. they are mapped only if received. If they are received and 
cannot be mapped, then an error is sent to the gsmSCF as detailed in clause 11. 

NOTE 3: These optional parameters may be absent, i.e. they are mapped only if received. 

Except for the Called Party Number the remaining mandatory ISUP IAM parameters are set as follows: 

a) Nature of connection indicators 

Satellite indicator: set as in an Originating MSC, 

Continuity check indicator: set as in Originating MSC, 

Echo control device indicator: set as in Originating MSC 

b) Forward Call Indicators 

National/international call indicator: set as in Originating MSC, 

End-to-end method indicator: 00 (no end-to-end method available), 

Interworking indicator: (no interworking encountered), 

End-to-end information indicator: (no end-to-end information available), 

ISDN User Part indicator: 1 (ISDN User Part used all the way), 
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ISDN User Part preference indicator: 00 (ISDN User Part preferred all the way), 
ISDN access indicator: (originating access non-ISDN), 

SCCP method indicator: 00 (no indication) 

c) Calling Party's Category 
00001010 (ordinary subscriber) 

d) Transmission Medium Requirement 
00000011 (3.1 kHz audio) 

The ISUP IAM optional parameter Propagation Delay Counter is set as in an Originating MSC. 

A.7 ReleaseCall operation 

Upon receipt of the ReleaseCall operation, the GMSC/gsmSSF (VMSC/gsmSSF) sends REL messages in both 
directions. The cause indicators parameter contains the releaseCallArg parameter of the ReleaseCall operation. 



A.8 InitiateCallAttempt operation 

On receipt of an InitiateCallAttempt operation, the GMSC/gsmSSF or VMSC/gsmSSF prepares to set up a new call leg 
in an existing call configuration, or to set up a new call, to the destination defined by the DestinationRoutingAddress 
parameter. The GMSC/gsmSSF or VMSC/gsmSSF does not send the ISUP IAM until it has received a 
Continue WithArgument operation, which contains additional information needed to populate the parameters of the 
ISUP IAM. 

Table A. 6 illustrates the mapping of parameters received in the InitiateCallAttempt operation to parameters sent in the 
ISUP IAM to the succeeding exchange. 

Table A.6 



CAP Operation 
InitiateCallAttempt (Note 1) 


ISUP message 
IAM 


DestinationRoutingAddress 


Called party number 


CallingPartyNumber 


Calling party number 




Transmission medium requirement (Note 2) (Note 4) 




Access transport (Note 3) (Note 4) 



NOTE 1: Optional parameters may be absent, i.e. they are mapped only if received. 

NOTE 2: The transmission medium requirement parameter field shall be set to "speech". 

NOTE 3: The "Bearer capability" and "High layer compatibility information" elements shall be filled in accordance 
with ETSI EN 300 403-1 [25] for speech call. 

NOTE 4: Only the minimum set of parameters indicating the fact that the call is a speech call is described here. 
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Annex B (normative): 

Mapping between CAP and MAP and mapping between 

CAP and SM-CP 

The Short Message signalling between the SMS-GMSC and the MSC or SGSN, for the transport of SM RP-DUs, is 
specified in 3GPP TS 29.002 [11]. The Short Message signalling between the MSC or SGSN and the MS, for the 
transport of SM RP-DUs, is specified in 3GPP TS 24.01 1 [10]. 



B.1 Mapping between CAP and MAP 

B.1.1 MO-SMS 

B. 1 . 1 . 1 ConnectSMS operation 

The Short Message TPDU is carried by a Short Message RPDU. The RPDU between the MSC or SGSN and the SMS- 
IWMSC is conveyed in the MAP MO-ForwardSM OPERATION. The MSC or SGSN shall obtain information from 
CAP OPERATION ConnectSMS and place it in MAP OPERATION MO-ForwardSM. 

Table B.1 



CAP ConnectSMS 


MAP MO-ForwardSM ARGUMENT 


CallingPartysNumber 


sm-RP-OA; CHOICE set to msisdn 


DestinationSubscriberNumber 


sm-RP-UI; TP-Destination-Address 


SMSCAddress 


sm-RP-DA; CHOICE set to serviceCentreAddressDA 



NOTE The encoding of "Signallnfo" in MO-ForwardSM is specified in 3GPP TS 23.040 [6]. 



B. 1 . 1 .2 EventReportSMS operation 



The MSC or SGSN may receive error information from the SMS-IWMSC, via the MAP OPERATION MO- 
ForwardSM ERROR. The MSC or SGSN shall obtain the error information from MAP OPERATION MO-ForwardSM 
and place it in the CAP OPERATION EventReportSMS. 

Table B.2 



CAP EventReportSMS 


MAP MO-ForwardSM ERROR 


MO_SMS Cause 


SM-DeliveryFailure; SM-DeliveryFailureCause; SM- 
EnumeratedDeliveryFailureCause 
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B.1.2 MT-SMS 

B.1 .2.1 InitialDPSMS operation (MT-SMS) 

The Short Message TPDU is carried by a Short Message RPDU. The RPDU between the SMS-GMSC and the MSC or 
SGSN is conveyed in the MAP MT-ForwardSM OPERATION ARGUMENT. The MSC or SGSN shall obtain 
information from the MT-ForwardSM MAP Message and place it in CAP InitialDPSMS. 

Table B.3 



CAP InitialDPSMS 


MAP MT-ForwardSM ARGUMENT 


CallingPartysNumber 


TP-Originating-Address from SMS-Deliver-TPDU. SMS- 
Deliver-TPDU is contained in sm-RP-UI. 


SMSCAddress 


sm-RP-OA 


TPShortMessageSpecificlnfo 


First OCTET of the TPDU. The TPDU is contained in sm- 
RP-UI. 


TPProtocolldentifier 


TP-Protocol-ldentifier of the TPDU. The TPDU is contained 
in sm-RP-UI. 


TPDataCodingScheme 


TP-Data-Coding-Scheme of the TPDU. The TPDU is 
contained in sm-RP-UI. 


TPValidityPeriod 


TP-Validity-Period of the TPDU. The TPDU is contained in 
sm-RP-UI. 



NOTE The encoding of "Signallnfo" in MT-ForwardSM is specified in 3GPP TS 23.040 [6]. 



B.1 .2.2 ReleaseSMS operation (MT-SMS) 



When the MSC or SGSN receives the CAP ReleaseSMS operation, it shall return a RP -ERROR RPDU to the SMS- 
GMSC. The RP-ERROR RPDU between the MSC or SGSN and the SMS-GMSC is conveyed in the MAP MT- 
ForwardSM OPERATION ERROR. 

Table B.4 



CAP ReleaseSMS 


MAP MT-ForwardSM ERROR 


RPCause 


SM-DeliveryFailure; sm-DeliveryFailureCause; sm- 
EnumeratedDeliveryFailureCause 



B.2 Mapping between CAP and SM-CP 

B.2.1 MO-SMS 

B.2.1 .1 InitialDPSMS operation 

The Short Message TPDU is carried by a Short Message RPDU. The RPDU between the MS and the MSC or SGSN is 
conveyed in the RP-DATA Relay Message. The MSC or SGSN shall obtain information from the RP-DATA Message 
and place it in CAP InitialDP OPERATION. 
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Table B.5 



CAP InitialDPSMS ARGUMENT 


SM-CP RP-DATA Message 


DestinationSubscriberNumber 


RP-User Data; TPDU; TP-Destination-Address 


SMSCAddress 


RP-User Data; RP-Destination Address 


TPShortMessageSpecificlnfo 


RP-User Data; TPDU; 1 st octet 


TPProtocolldentifier 


RP-User Data; TPDU; TP-Protocol-ldentifier 


TPDataCodingScheme 


RP-User Data; TPDU; TP-Data-Coding-Scheme 


TPValidityPeriod 


RP-User Data; TPDU; TP-Validity-Period-Format 



B.2.1 .2 ReleaseSMS operation 



When the MSC or SGSN receives the CAP ReleaseSMS operation, it shall return a RP -ERROR RPDU to the MS. The 
RP-ERROR RPDU between the MSC or SGSN and the MS is conveyed in the RP-ERROR Relay Message. The MSC 
or SGSN shall obtain the RPCause from the CAP ReleaseSMS OPERATION and place it in the RP-ERROR Message. 

Table B.6 



CAP ReleaseSMS ARGUMENT 


SM-CP RP-ERROR Message 


RPCause 


RP-Cause 



B.2.2 MT-SMS 

B. 2.2.1 ConnectSMS operation 

When the MSC or SGSN receives the ConnectSMS operation, it shall use the received information to replace data in the 
Short Message SMS-DELIVER TPDU. The SMS-DELIVER TPDU is carried in a RP-MT-DATA RPDU. The RP-MT- 
DATA RPDU between the MSC or SGSN and the MS is conveyed by the SM-CP CP-Data Message. 

Table B.7 



CAP ConnectSMS 


SM-CP RP-DATA Message 


CallingPartysNumber 


RP-User Data; TPDU; TP-Originating-Address 



B. 2.2.2 EentReportSMS operation 

When the MSC or SGSN receives the RP-ERROR RPDU from the MS, it shall send the RP-Cause to the gsmSCF. The 
RP-ERROR RPDU between the MS and the MSC or SGSN is conveyed in the RP-ERROR Relay Message. The MSC 
or SGSN shall obtain the RPCause from the RP-ERROR Message and place it in CAP EventReportSMS. 

Table B.8 



CAP EventReportSMS 


SM-CP RP-ERROR Message 


EventSpecificlnformation 


RP-Cause 
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Annex C (informative): 
Change history 

Comments on CAMEL Phase 4 Rel-6 

For Release Rel-6, the version of module CAP-U-ABORT-Data is aligned with the other CAP modules; the 
module version is increased to version5(4). The increase of module version number does not affect the data type 
definitions contained within the module. 

CAP Operation 'SpecialisedResourceReport' is spelled with a 'z' (American spelling) in ASN. 1 . Therefore, TS 
29.078 shall write in the text SpecializedResourceReport with a 'z' consistently. 

For consistency purposes, module CAP-GPRS-ReferenceNumber is placed in a separate section. All CAP Modules 
(starting with BEGIN and ending with END) are specified in a separate section. 

The Rel-5 history overview ('How CAMEL Phase 4 Rel-5 Version 5.0.0 was created') is removed from the Rel-6 
version of the present specification. 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


R 
ev 


Subject/Comment 


Old 


New 


2003-12 


CN#22 


NP-030527 


332 


1 


Collective CR for Rel-6 Enhanced Dialled Services 


5.6.0 


6.0.0 


2003-12 


CN#22 


NP-030528 


343 


1 


Change of position armed with criteria 


5.6.0 


6.0.0 


2004-03 


CN#23 


NP-040138 


350 


2 


Enhancement of Event Specific Information for DP 'Change 
of Position' 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040095 


352 


1 


CAMEL4 SCUDIF notification during active call for prepay 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040096 


356 


1 


LLC passes on the gsmSSF - gsmSCF interface 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040136 


360 




Correction to description of Service Interaction Indicators 
Two parameter 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040136 


361 




Correction to temporary connection establishment 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040137 


362 




Correction to SplitLeg and MoveLeg preconditions 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040138 


363 




Correction to Disconnect Leg preconditions 


6.0.0 


6.1.0 


2004-03 


CN#23 


NP-040138 


364 




Correction to GPRS protocol definition 


6.0.0 


6.1.0 


2004-06 


CN#24 


NP-040249 
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1 


Enhancement to User Interaction 


6.1.0 


6.2.0 


2004-06 


CN#24 


NP-040249 


367 


1 


Adding missing ROS Object Identifier 


6.1.0 


6.2.0 


2004-06 


CN#24 


NP-040207 


370 


1 


Mapping between ICA and IAM 


6.1.0 


6.2.0 


2004-06 


CN#24 


NP-040207 
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Correction to Tssf timer 


6.1.0 


6.2.0 


2004-06 


CN#24 


NP-040207 
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Correction to ERB pre-condition for gsmSSF FSM state 


6.1.0 


6.2.0 


2004-06 


CN#24 


NP-040207 
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2 


Correction to Move Leg pre-condition 


6.1.0 


6.2.0 


2004-06 


CN#24 


NP-040249 


375 




Correction to First Digit Timer for Prompt&Collect 


6.1.0 


6.2.0 


2004-09 


CN#25 


NP-040405 


380 




Support of User-to-User Information (UUI) in CAMEL 
InitialDP operation 


6.2.0 


6.3.0 


2004-09 


CN#25 


NP-040397 


382 


2 


Clarification on the handling of operation invocation when 
LinkedID is missing although expected 


6.2.0 


6.3.0 


2004-09 


CN#25 


NP-040406 


383 




Correction to usage of ACM for CAP ETC and CAP CTR 


6.2.0 


6.3.0 


2004-09 


CN#25 


NP-040406 


384 




Correction to Cancel procedure description 


6.2.0 


6.3.0 


2004-09 
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NP-040406 
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Correction to SplitLeg ASN.1 description 


6.2.0 


6.3.0 


2004-09 
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Correction to Apply Charging Report procedure 
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6.3.0 


2004-09 
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NP-040406 
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Correction to Assist Request Instructions procedure 


6.2.0 


6.3.0 


2004-09 


CN#25 


NP-040406 
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Correction to Call Information Request and Report 


6.2.0 


6.3.0 


2004-09 


CN#25 


NP-040406 


389 




Correction to Tssf timer setting for SMS control 


6.2.0 


6.3.0 


2004-12 


CN#26 


NP-040544 


390 




Correction of wrong TS numbers in references 


6.3.0 


6.4.0 


2005-06 


CT#28 


CP-050103 
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1 


Additions to CAP for trunk originated services 


6.4.0 


7.0.0 


2005-09 


CT#29 


CP-050312 
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1 


Additions and clarifications to CAP for trunk originated 
services 


7.0.0 


7.1.0 


2005-12 
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CP-050626 
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1 


Support of an Operation Arg and Errors for 
Collectlnformation 


7.1.0 
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CP-060311 
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1 


Addition of information related to service change 


7.2.0 


7.3.0 


2007-09 
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CP-070540 
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2 


AC/ACR Handling 


7.3.0 


7.4.0 
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CP-070540 


0400 




QoS Extension 


7.3.0 


7.4.0 
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